The certificate was made for CN=192.168.16.33. What breaks when the laptop gets a different address from DHCP, and why does the client check the name at all?
Every client rejects the server with a name mismatch, even though the key and certificate are unchanged: the certificate now names an address nobody is connecting to. The check exists because a trusted certificate must also be the certificate for this server, otherwise any trusted certificate could impersonate any server.
Verifying a certificate answers two separate questions:
- Is it genuine? Signed by someone I trust (here: is it exactly the pinned certificate).
- Is it for the server I asked for? Does the name in the certificate match the host in the URL.
Both are needed. In a normal CA setup, every website has a genuine certificate from a trusted CA; without the name check, the certificate of attacker.example would be accepted for bank.example. With a single pinned certificate the risk is smaller, but clients still apply the check, so the certificate must name the address that is actually used.
Where the name lives:
| Field | Status |
|---|---|
| Common Name (in the subject) | The historical place. RFC 9525 says it must no longer be used to identify a service; some clients still fall back to it when no SAN is present |
| Subject Alternative Name (extension) | The standard place: DNS:garage.local, IP:192.168.16.33. Can list several names |
Fixes for a moving address: give the server a DHCP reservation or static IP, use a hostname (local DNS or mDNS such as garage.local) and put it in the SAN, or list every address the server may have. Turning the check off (ESP-IDF's skip_cert_common_name_check) works but throws away half of the verification.
Go deeper:
RFC 9525 — Service identity in TLS — the current rules: identities go in subjectAltName, not in the Common Name.- Wikipedia — Subject Alternative Name — the extension and the name types it can carry.