SSTP certificate mismatch: the name your server must present

An SSTP client accepts the server only after TLS validation succeeds, and that check compares a name, a chain and a purpose. The name comes from the connection profile, not from the address you happen to be able to ping. When one of the three does not line up, the client reports a certificate problem and never reaches the login prompt.

The profile name decides what gets checked

SSTP runs TLS over TCP 443, so the client behaves like any other TLS client: it takes the hostname from the profile, requests that name, and compares the certificate against it. Type an IP address into the profile and the comparison becomes an IP address comparison, which most server certificates do not satisfy.

A browser test can therefore succeed while the VPN fails, because the browser used a different name than the profile does. The same split appears when split-horizon DNS resolves the VPN hostname to an internal address while the browser reached a public one. Align the profile with the documented hostname first, then compare certificates. Anything else you change before that is guesswork.

What the server certificate has to carry

Modern clients match against the subject alternative name extension, so the hostname has to appear there as a DNS entry. A common name alone is not enough for current validation stacks, and a wildcard covers one label rather than any subdomain you invent. Three certificates illustrate the boundary: the right name with the wrong purpose validates the identity and then fails the purpose check, the right name and purpose with a missing intermediate fails the chain, and a name that only appears in the common name fails before either of those matter.

The certificate also needs the server authentication purpose, the extended key usage value named in Microsoft's SSTP specification, serverAuth with object identifier 1.3.6.1.5.5.7.3.1. Key usage and a valid chain round out the set. A certificate that exists on the server, issued for the right name but for client authentication only, still fails.

Verify the chain and the clock before credentials

Time and trust failures produce the same visible result as a name mismatch, and both are cheaper to diagnose than a password problem. Check the server's clock and the client's clock, then read the chain the way the client sees it:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

The first command prints the name, the validity window and the alternative names the client will compare against. The second reports verification errors with the chain as presented, which is where a missing intermediate shows up. On Windows the time service query tells you whether the clock is being corrected or has simply drifted.

An internal CA adds one more condition: the client has to trust that CA. Install the organizational root through its approved distribution channel, not from a page offering a replacement certificate, because that decision is the whole trust model in miniature.

Server validation and user authentication are sequential stages with different failures. A certificate error means the client never trusted the server, while a rejected password means it trusted the server and the credentials were wrong. Turning off certificate validation to reach the password prompt removes the guarantee instead of repairing it. To prove the rest of the path works, test the same hostname and port from a client that already trusts the chain, and leave the deployed profile alone.

Fix the name or fix the certificate, then retest

Three conditions decide the repair. If the profile name is wrong, correct the profile or add the missing name to the certificate. If the chain is incomplete, install the intermediate on the server. If the purpose is wrong, reissue rather than patch around it.

After the change, reconnect with the supported client and confirm that the login prompt appears, then that the tunnel comes up. Note the hostname used, the issuer and the expiry date in the ticket. That record is what makes the next renewal a scheduled task instead of another outage, and it also shows the next person which of the three conditions was actually broken.