Citizens call https://permits.city.example for a civic API, but the installed certificate lists only CN/SAN for dev.permits.city.example. Clients reject the handshake. What is wrong with the application certificate configuration?
Select an answer to reveal the explanation.
Short Explanation
The name on the badge has to match the door you open—clients check SAN/CN against the URL host. A dev-only name on the production hostname is simply the wrong identity installed.
Full Explanation
TLS hostname verification compares the name clients use in the URL to CN/SAN on the certificate. Citizens calling https://permits.city.example while the installed certificate lists only CN/SAN for dev.permits.city.example will reject the handshake because the certificate identity does not match the hostname in the URL. Fixing application certificate configuration means issuing and installing a cert that includes permits.city.example (and needed names), not asking users to ignore warnings.
Claiming ECDSA instead of RSA is always refused by browsers fails—modern clients accept ECDSA certificates when chains and hostnames are valid. Asserting TLS cannot protect APIs unless IPsec is also configured fails by conflating transport layers; HTTPS alone is the API encryption path on the exam. Requiring every public CA root in the leaf SAN field misunderstands PKI: SANs carry server identities, not the world’s root store.
Exam caveat: wildcards and multi-SAN certs are valid when they cover the called name; IP SANs are needed if clients use raw IPs. Corporate MITM middleboxes are a separate trust-store problem from leaf hostname mismatch.
Operational check: reproduce the handshake failure against the civic URL, install a corrected SAN cert, and confirm clients complete TLS without name-mismatch errors.