HTTP.sys HTTPS binding validation only checks IP:port bindings, so a server with SNI-only bindings on 443 cannot start

[Stemonik]

Summary

With UseHttps, TDextHttpSysEngine.Start first validates the certificate binding (RegisterSslBinding). The validation only looks at IP:port bindings. When port 443 has only hostname (SNI) or central-store bindings, it raises and the service doesn't start, even though HTTP.sys would serve HTTPS for that prefix.

Where

Sources/Server/Dext.Server.HttpSys.pas, TDextHttpSysEngine.RegisterSslBinding. It queries HttpServiceConfigSslCertInfo with HttpServiceConfigQueryExact on 0.0.0.0:<port> (or the configured IPv4 address), and on ERROR_FILE_NOT_FOUND raises:

No http.sys SSL binding exists for +:443. Inspect or provision it with: netsh http show sslcert ipport=+:443

It never checks either of the other two binding kinds:

• HttpServiceConfigSslSniCertInfo: hostname bindings. IIS creates these for every site with "Require Server Name Indication", and win-acme creates them when it installs a certificate for such a site;
• HttpServiceConfigSslCcsCertInfo: central certificate store bindings.

Why it matters

Running a Dext service on HTTP.sys next to IIS on the same 443 is a natural deployment: HTTP.sys routes by URL prefix, and the service reuses the certificate IIS/win-acme already manage and renew. Where those bindings are all per-hostname, the service can't start.

To be transparent: we found this reading the code while deploying to such a server, not by watching it fail. Our server also has a 0.0.0.0:443 binding, so it starts fine.

Suggested fix (either, or both)

• (a) When the IP:port lookup returns ERROR_FILE_NOT_FOUND, look for an SNI binding for the host in the URL prefix (and a CCS binding for the port) before raising.
• (b) An option to skip the check (e.g. ValidateSslBinding, default True), for setups where bindings are managed outside the service.

A small related one: with the address +, the message suggests netsh http show sslcert ipport=+:443, which netsh rejects. The query itself uses 0.0.0.0, so the message could print that.

Checked against f440e79a.

🤖 Generated with Claude Code

[cesarliws]

Thank you for bringing this up! This is a very insightful observation and an important deployment scenario.

You are spot-on: in shared environments (such as coexisting with IIS on port 443 or using tools like win-acme), SSL bindings are very commonly provisioned as SNI (sslcert hostnameport=...) or CCS rather than IP-specific bindings (ipport=...). The current fail-fast check in RegisterSslBinding only queries HttpServiceConfigSslCertInfo, which falsely blocks the engine from starting even when HTTP.sys is fully capable of serving TLS for the configured host prefix.

I also agree regarding the netsh message outputting ipport=+:443 when FAddress is +.

Proposed Plan

We'd love to address this with both suggestions:

1. Option to bypass validation:
   Add a configuration property to TDextHttpSysOptions (e.g. ValidateSslBinding: Boolean, defaulting to True). When set to False, the engine skips RegisterSslBinding altogether, accommodating setups where certificate bindings and SNI lifecycle are managed externally (e.g., IIS, Group Policy, win-acme).

2. Support SNI queries & fix netsh guidance:

   • If the IP:port query returns ERROR_FILE_NOT_FOUND and the server is bound to a specific host (or when SNI is available), fallback to query HttpServiceConfigSslSniCertInfo before giving up.
   • When printing the netsh hint in the exception message, use 0.0.0.0:<port> if FAddress is + or empty.

If you are interested in submitting a PR for either part (or both), you are more than welcome! Otherwise, I will schedule this fix for an upcoming release. Thanks again for the detailed feedback!