4 ms·

The certificate at no-subject.badssl.com has an empty subject field, but it still contains the subject domain name in the Subject Alternative Names (SAN) extens

by agwa 10y ago

The certificate at no-subject.badssl.com has an empty subject field, but it still contains the subject domain name in the Subject Alternative Names (SAN) extension. Using the original X.509 subject field for the domain name has been deprecated for some time, and modern TLS clients look at the SAN extension instead.

tialaramex 10y ago
In particular, the usual algorithm is this: 1. Does this certificate have at least one SAN dnsName or SAN ipAddress? If so, go to step 3. 2. Look at the certificate Subject for a Common Name, is this definitely a valid Fully Qualified Domain Name or an IP address written out as ASCII text? If so, pretend we found exactly one SAN, with this dnsName or ipAddress in it, otherwise abort, invalid certificate. 3. Check that one of the SANs we found matches the server we expected to talk to, for URLs in a browser this means exactly matching the name in the URL so e.g. even if www.example.com has address 10.11.12.13, a certificate for 10.11.12.13 is no good for URLs starting https://www.example.com/ https://www.example.com/ Getting rid of step 2 is a desired end state for popular web browsers, because that step is complicated, and complication increases the chance of making a mistake. Mozilla has signalled they intend to abolish step 2 for public trusted CAs (not any CAs added by the user) and Chrome has talked about the same. The public CAs have been required for many years to include a SAN, but the usual incompetence and inertia interferes in enforcing this. People who bought a "perfectly good" certificate which is missing SANs will invariably blame their web browser, not the certificate vendor who sold them a defective product. Common Names are notionally limited to 64 characters in length, most FQDNs are shorter, but definitely not all of them, especially in some countries where long-winded names for things have a strong history like Germany. So this is another reason to stop trying to squeeze FQDNs into the Subject's Common Name. Common Names remain useful for naming certificates that aren't for a TLS service, such as CA certificates themselves, or indeed personal client certificates, just not really for web sites.

by agwa 10y ago

tialaramex 10y ago

In particular, the usual algorithm is this: 1. Does this certificate have at least one SAN dnsName or SAN ipAddress? If so, go to step 3. 2. Look at the certificate Subject for a Common Name, is this definitely a valid Fully Qualified Domain Name or an IP address written out as ASCII text? If so, pretend we found exactly one SAN, with this dnsName or ipAddress in it, otherwise abort, invalid certificate. 3. Check that one of the SANs we found matches the server we expected to talk to, for URLs in a browser this means exactly matching the name in the URL so e.g. even if www.example.com has address 10.11.12.13, a certificate for 10.11.12.13 is no good for URLs starting https://www.example.com/ https://www.example.com/ Getting rid of step 2 is a desired end state for popular web browsers, because that step is complicated, and complication increases the chance of making a mistake. Mozilla has signalled they intend to abolish step 2 for public trusted CAs (not any CAs added by the user) and Chrome has talked about the same. The public CAs have been required for many years to include a SAN, but the usual incompetence and inertia interferes in enforcing this. People who bought a "perfectly good" certificate which is missing SANs will invariably blame their web browser, not the certificate vendor who sold them a defective product. Common Names are notionally limited to 64 characters in length, most FQDNs are shorter, but definitely not all of them, especially in some countries where long-winded names for things have a strong history like Germany. So this is another reason to stop trying to squeeze FQDNs into the Subject's Common Name. Common Names remain useful for naming certificates that aren't for a TLS service, such as CA certificates themselves, or indeed personal client certificates, just not really for web sites.