Quick answer: 0x80090322 (SEC_E_WRONG_PRINCIPAL) means the client connected to a hostname, but the certificate or Kerberos principal presented by the server is for a different name. Fix the SAN on the cert, or fix the SPN registration, and the error disappears.
I've seen this one bite people in three common spots: an internal LDAPS setup where someone generated a cert with the short name (dc01) instead of the FQDN (dc01.corp.local), a SQL Server 2019 box where the cert was issued to the wrong hostname after a VM rename, and a web farm where a load balancer was terminating TLS with a cert that only had the backend server name in the SAN. All three threw 0x80090322. The client didn't care about the story behind the cert — it just refused to trust it, because the name it dialed didn't line up with what the server presented.
Schannel throws this error. It's not an application error, it's a security layer error. That matters because the app (IIS, SQL, RDP, LDAPS) usually just relays it. Your logs will show something like "The remote certificate is invalid according to the validation procedure" or an Event ID 36888 in the System log. Don't start debugging the app. Start at the certificate and the SPN.
Fix 1: Check the certificate SAN first
Nine times out of ten, this is the problem. The certificate's Subject Alternative Name field is missing the hostname the client is using. Subject CN doesn't count anymore in modern validation — has to be in the SAN.
On the server, run:
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, DnsNameList, Thumbprint, NotAfterLook at DnsNameList. If the client is connecting to app01.corp.local and the SAN only has app01, there's your cause. Same if the SAN has the wrong domain suffix, or if it's a public CA cert with only www.example.com when clients are hitting the internal name.
Reissue the cert with all the names clients actually use — FQDN, short name if you must, and any CNAMEs. Then rebind it. For IIS: netsh http show sslcert will show what's bound to the IP:port, then netsh http delete sslcert and re-add with the new thumbprint. For SQL, use the SQL Server Configuration Manager to swap the cert, then restart the SQL service.
Fix 2: Hunt duplicate or missing SPNs
If you've confirmed the cert is fine, this is a Kerberos problem. The service principal name registered for the account doesn't match the name the client requests. Common triggers: renamed servers, cloned VMs with the same SPN, or a service account that got moved and never had its SPNs migrated.
Check duplicates:
setspn -XThat lists SPNs registered on more than one account. If your target hostname shows up twice, delete the stale one:
setspn -D MSSQLSvc/sql01.corp.local:1433 CORP\OLDSQLACCTThen register it on the correct account:
setspn -A MSSQLSvc/sql01.corp.local:1433 CORP\SQLSVCKerberos caches aggressivly. Purge tickets on both the client and server after this change, or you'll swear the fix didn't work:
klist purgeFix 3: Verify the client is using the right name
Sometimes the server is configured perfectly and the client is just dialing the wrong thing. A connection string pointing at an IP address instead of the FQDN will fail validation, because the cert SAN almost never includes an IP. Same with a hardcoded short name when the cert only has the FQDN.
Check your client config. For LDAPS, it's usually something like LDAP://192.168.1.10:636 — replace that IP with the FQDN. For SQL, swap Server=10.0.0.5,1433 for Server=sql01.corp.local,1433. For .NET apps, the same rule applies in Web.config or appsettings.json.
Alternative fixes if the above don't stick
- Chain of trust broken: If the root or intermediate CA isn't installed on the client, you'll get 0x80090322 even with a perfect SAN. Push the root into Trusted Root Certification Authorities via GPO. Verify with
certutil -verify -urlfetch <certfile.cer>. - Hostname file mismatch: A record in the hosts file can override DNS and send clients to a name the cert doesn't cover. Check
C:\Windows\System32\drivers\etc\hostson both sides. - SNI not set: In IIS, if you host multiple sites on the same IP and port 443, SNI must be enabled on the binding, and the client must send the right hostname. Old clients that don't do SNI will hit the default binding and fail.
- Strong name mismatch in RDP: For RDP specifically, the cert in the RDP listener has to match the name in the .rdp file. Update via
Set-RDSessionHostor swap the cert in the RDP-Tcp listener settings.
Prevention
Build the SAN into your cert template before you issue anything. Every internal cert you push from your enterprise CA should include at minimum the FQDN, and ideally the short name plus any CNAMEs clients use. If you're using a public CA for an internal service (don't, but people do), make sure the name resolves the same way from every client subnet.
Second, treat SPN registration as part of your server provisioning checklist. When you rename a server or migrate a service account, run setspn -X before and after. Duplicate SPNs are silent until a client fails auth, and then they're loud.
If you want to catch these before users do, monitor the System log for Event ID 36888 (Schannel) and 4769 with result code 0x7 on your DCs. Both signal name mismatches long before the help desk ticket shows up.