At its core, HTTPS is HTTP over TLS (Transport Layer Security). The TLS protocol requires a certificate during the handshake process. Here's why:

ClientHello  ---->
               <----  ServerHello
               <----  Certificate* (MUST send certificate)
               <----  ServerKeyExchange
               <----  ServerHelloDone

The asterisk in RFC 5246 clearly states: "The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication."

Some infrastructure teams confuse these scenarios:

• Self-signed certificates: Still certificates, just not from trusted CAs
• Anonymous Diffie-Hellman: An obsolete mode that most browsers now block
• Certificate-less internal setups: Often actually using enterprise PKI

Attempting HTTPS without a certificate in IIS fails explicitly:

PS C:\> New-WebBinding -Name "Default Web Site" -Protocol https -Port 443 -IPAddress *
New-WebBinding : The binding is invalid. HTTPS bindings must have a certificate associated with them.

Without certificate verification:

1. No server authentication (vulnerable to MITM attacks)
2. No encryption strength guarantees
3. Browser warnings that defeat the purpose of HTTPS

For developers needing quick HTTPS without CA certificates:

# PowerShell self-signed cert generation:
$cert = New-SelfSignedCertificate 
    -DnsName "dev.local" 
    -CertStoreLocation "cert:\LocalMachine\My"

# IIS binding:
New-WebBinding -Name "Default Web Site" -Protocol https -Port 443 -IPAddress * -SslFlags 1

Modern tools like mkcert provide better developer experience while maintaining proper certificate chains.

HTTPS fundamentally requires a certificate - the choice is between CA-signed, self-signed, or enterprise PKI certificates. The infrastructure team's claim likely refers to visual trust indicators rather than protocol requirements.

Your infrastructure team's statement contains a critical misunderstanding of how HTTPS works at the protocol level. The SSL/TLS protocol (which enables HTTPS) requires certificate validation as part of the handshake process. Here's why:

// Example from Node.js HTTPS server setup
const https = require('https');
const fs = require('fs');

// This WILL FAIL without certificate files
const options = {
  key: fs.readFileSync('server.key'),  // Required
  cert: fs.readFileSync('server.cert') // Required
};

https.createServer(options, (req, res) => {
  res.end('HTTPS response');
}).listen(443);

While commercial certificates provide identity verification, any certificate is fundamentally required:

• CA-signed certificates (trusted verification)
• Self-signed certificates (untrusted but functional)
• Wildcard certificates (domain pattern matching)

In IIS, attempting HTTPS without a certificate results in this error:

HTTP Error 403.7 - Forbidden
SSL certificate is required

The binding configuration in applicationHost.config clearly shows the requirement:

<binding protocol="https" bindingInformation="*:443:" 
         sslFlags="0" certificateHash="" 
         certificateStoreName="My" />

Possible confusion stems from:

1. Testing environments that automatically generate self-signed certs
2. Misinterpretation of "encrypted but unverified" connections
3. Confusion between HTTP/2 (which can use plaintext) and HTTPS

The TLS 1.2/1.3 handshake sequence demonstrates the certificate requirement:

1. ClientHello
2. ServerHello
3. Certificate*  (*MANDATORY for HTTPS)
4. ServerKeyExchange
5. ServerHelloDone
...

If avoiding certificate management is the goal, consider:

# Nginx redirect to HTTP (BAD PRACTICE)
server {
    listen 443 ssl;
    ssl_certificate /dev/null;  # Will fail
    ssl_certificate_key /dev/null;
    return 301 http://$host$request_uri;
}

For development, automated tools like mkcert handle certificate generation locally:

# Generate valid local certificate
mkcert -install
mkcert example.local

Operating without proper certificates:

• Breaks TLS specification (RFC 8446)
• Creates MITM vulnerability points
• Violates PCI DSS and other compliance standards

HTTPS fundamentally requires certificate material - whether trusted or self-signed. While identity verification (the "green lock") requires CA-signed certs, the encryption layer itself demands cryptographic material that only certificates provide.