Subject Alternative Names: How a VPN Server Is Identified

Your client rejects a certificate whose chain validates cleanly, and the error says the name does not match. That message is not about who signed the certificate. It is about the subject alternative name extension, which carries the identities the certificate is allowed to represent, and about whether the identity you configured appears there in the right form. Trust answers who signed it, while the name check answers which host it belongs to.

What the client actually compares

The client turns your configuration into a reference identity: a hostname, an address, or a protocol-specific identifier. It then searches the certificate for that identity, applying the matching rules of the protocol in use. Only entries of the same type count, so a DNS entry cannot satisfy an address, and the comparison happens whether or not a human ever looks at the certificate.

When the reference identity is missing from that extension, the check fails even if the legacy common name matches. A certificate can be legitimately issued to a company and still be the wrong one for vpn.example.com if the name was never included. The failure is a name mismatch even though the certificate is genuine.

DNS names and IP addresses are separate entries

A profile that points at 203.0.113.10 while the certificate lists only vpn.example.com is rejected, because the packets arrive but the identity does not match. DNS names and address literals are stored as different entry types, and one never substitutes for the other. That is why a service can be reachable by address and still unusable through a profile that uses that address.

Wildcards obey their own rules as well: a wildcard covers a single label, not every name beneath a domain. DNS comparison is case-insensitive, while other identifier types are not, so a value that looks identical on screen can fail a strict comparison. Check the matching rules for the identity type in use rather than comparing strings by eye. Adding a name to the extension is an issuance decision, not something a client setting can supply.

Inspect the certificate the connection really used

Read the material presented by the live endpoint, not a file copied from an administration page. A load balancer or a replacement instance can present something different from the certificate that was uploaded months ago, and that difference is invisible in a console.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

The subject alternative name block, the issuer chain and the validity period all belong in the same read, because a name mismatch and an expiry produce different errors. Compare each name in that block against the identity configured in the profile, character by character, and note which type it is. Repeating the command against the address form of the endpoint shows whether the certificate covers both identities or only one. A friendly subject display in a management console is not a validation result and says nothing about which names the extension contains.

The common name is not the modern source of truth

Browsers and most TLS libraries now ignore the common name for hostname matching and consult the extension instead. Some VPN clients still compare the common name first or fall back to it when the extension is absent, which is how one certificate can pass a browser and fail a client. The same name check can pass on one platform and fail on another without the certificate changing at all.

Find out which field your client reads before deciding the certificate is wrong. Two clients on the same endpoint can disagree, and the disagreement is information about the client rather than about the certificate.

Repair issuance or the profile, not the check

When a profile was built around an alias, either repoint it at the documented hostname or reissue the certificate for the alias and deploy it in a planned window. Silencing the warning is not a third option, because the check is the only step that ties a signed certificate to this particular host. Removing it means any certificate from the same authority can stand in for the server you meant to reach.

Renewal should preserve the intended names and purpose rather than merely moving the expiry date forward. A renewal that drops a name is a new outage scheduled for the next restart, and it usually arrives without warning because the old certificate was still valid when the change was made.

Record the expected identity, the names that were presented and the chain that signed them. That record turns the next renewal into a comparison instead of an investigation. The extension definition is in RFC 5280 if you need to check a specific issuance.