HTTP, HTTPS, and SSL in IIS: Where Protocol Boundaries Fail in Production
By the time applications reach production, HTTP is usually treated as a solved problem.
Requests arrive.
Responses are returned.
Encryption is assumed to be a configuration detail.
When IIS is introduced, that assumption quietly breaks.
Many IIS production failures are not caused by application logic, identity, or permissions directly—but by how IIS binds domains, terminates SSL, selects certificates, and enforces protocol rules before application code ever runs.
The First Symptom: HTTPS “Works” Until It Doesn’t
A familiar production pattern looks like this:
HTTPS works in a browser
Health checks pass
APIs respond correctly
Service-to-service calls fail
Authentication flows break
TLS errors appear intermittently
Certificates appear valid.
Ports are open.
Nothing changed in the application.
At this point, debugging usually moves toward code or client libraries, even though the failure is occurring before the request reaches the application.
Where HTTPS Actually Terminates in IIS
In IIS, HTTPS does not terminate inside your application.
It terminates in HTTP.sys, the kernel-mode HTTP listener.
This means:
TLS negotiation happens before IIS routing
Certificate selection happens before application execution
Domain-to-certificate mapping is resolved before any middleware runs
By the time a request reaches your application:
TLS has already succeeded or failed
the certificate has already been selected
protocol decisions are already final
Your application does not “handle SSL”.
It receives the outcome of IIS handling SSL.
Domains and Hostnames Are Part of the Protocol Contract
In IIS, HTTPS is not bound only to a port.
It is bound to a combination of protocol, IP address, port, and hostname.
This is why:
https://localhostworkshttps://mydomain.examplefailsthe same site behaves differently depending on how it is accessed
The hostname is evaluated before the request is forwarded to the application.
If the incoming hostname does not match a valid binding:
the request may be rejected
the wrong certificate may be presented
the connection may terminate without reaching application code
From the application’s perspective, the request never existed.
What “SSL Enabled in IIS” Actually Means
In production discussions, it is common to hear:
“SSL is enabled in IIS.”
This statement is incomplete.
For HTTPS to function correctly in IIS:
an HTTPS binding must exist
a certificate must be associated with that binding
the certificate must be usable by HTTP.sys
the certificate chain must be resolvable
the private key must be accessible
the hostname must match the binding context
If any one of these conditions fails, HTTPS may break selectively, not globally.
This selective failure is what makes SSL issues so difficult to diagnose.
The Certificate Store Reality
Certificates used by IIS are not stored in the application.
They live in Windows certificate stores, typically:
Local Machine → Personal
Local Machine → Web Hosting
This distinction matters because:
browsers use user-level stores
IIS uses machine-level stores
certificate presence does not imply certificate usability
A certificate can:
appear installed
be trusted
be unexpired
…and still be unusable by IIS.
Common causes include:
missing private-key permissions
installation into the wrong store
incomplete certificate chains
manual installation differences across servers
These failures surface as protocol errors, not certificate errors.
Bindings Are Protocol Rules, Not Convenience Settings
In IIS, a binding is not just metadata.
It defines:
which protocol stack applies
which certificate is eligible
which hostnames are accepted
which requests are allowed to proceed
Bindings can exist and still be incorrect.
Common production scenarios:
certificate exists but hostname mismatch
multiple bindings compete unexpectedly
wildcard certificates behave differently across environments
HTTPS works for browsers but fails for services
From IIS’s perspective, these are not misconfigurations.
They are rule violations.
HTTP and HTTPS Are Not Symmetric Under IIS
Many applications assume HTTPS is simply HTTP with encryption.
Under IIS, this is false.
HTTPS requests are subject to:
stricter validation
earlier rejection
different timeout behavior
different error visibility
This explains why:
HTTP works
HTTPS fails
redirects loop
headers disappear
requests never reach application logs
The protocol boundary is enforcing rules the application never sees.
Why TLS Failures Produce Misleading Errors
TLS-related failures often surface as:
generic HTTP 500 responses
connection resets
handshake timeouts
authentication failures
They rarely surface as:
clear certificate diagnostics
actionable error messages
application exceptions
This happens because:
TLS fails before application code runs
logging depends on pipeline stages that were never reached
HTTP.sys rejects invalid requests early
By the time logs are examined, the request no longer exists.
Common Production Signals
When protocol-level failures occur under IIS, engineers usually see:
In IIS Logs
Missing entries for HTTPS requests
Requests logged with generic status codes
HTTP requests logged normally while HTTPS requests are absent
These indicate failures before request routing.
In Application Logs
No logs for failing HTTPS requests
Startup logs present, but no request-level activity
Authentication or certificate-dependent code never executed
The application was never invoked.
In Clients or Services
TLS handshake failures
Connection resets
Timeouts without HTTP responses
Authentication failures without certificate warnings
Browsers often recover silently.
Services rarely do.
Behavioral Clues
Works in browser, fails in background service
Works on one server, fails on another
Works after IIS restart, fails later
Works for one domain, fails for another
Works over HTTP, fails over HTTPS
Each of these points to protocol enforcement, not application logic.
Why These Failures Are Misdiagnosed
These symptoms are often attributed to:
unstable networks
load balancers
flaky certificates
transient infrastructure issues
In reality, they are deterministic outcomes of:
binding mismatches
certificate selection failures
hostname evaluation
protocol enforcement in HTTP.sys
Without visibility into this boundary, the failures appear random.
What IIS Is Enforcing at the Protocol Layer
IIS enforces:
strict hostname-to-binding mapping
deterministic certificate selection
protocol correctness over flexibility
minimal tolerance for ambiguity
Applications often assume:
protocol transparency
certificate availability
symmetric HTTP/HTTPS behavior
Failures occur when these assumptions collide.
Closing Thought
When HTTP or HTTPS fails under IIS, the application is often blamed first.
In reality, the failure usually occurs before the application has any opportunity to participate.
IIS is not breaking SSL arbitrarily.
It is enforcing protocol, domain, and certificate rules that applications rarely model explicitly.
Until those boundaries are understood, HTTPS issues under IIS will continue to feel environment-specific, inconsistent, and opaque.
They are none of those things.
They are enforcement.
