Is SubjectAlternativeName in X.509 always used for DNS Names?

Question

X.509 certificates as of RFC5280 offer the two fields "Subject" and "Subject Alternative Name" that can be used to describe the Subject of the certificate (e.g. a Domain example.com). Section 4.2.1.6 of RFC5280 reads:

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). […] Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field […]

My understanding is that in all X.509 conforming certificates the contents of the subject field must also be included in the "SubjectAlternativeName" field.

In which case is it necessary to check the "Subject" field of a certificate?

Do I, for compatibility reasons, need to check the "Subject" field? Do (non-conforming) X.509 certificates exist in the wild that don't use the "SubjectAlternativeName" field?

I'm interested in this question in general, but if you have specific knowledge about how this is commonly handled in wifi security (e.g. PEAP), please include it in your answer.

Answer 1

If you want to stay general, then the answer will be "it depends".

The cite from RFC implies the following: if the entity is a subject for validation (e.g. certificate is mapped to a specific entity in directory), its identity MUST be presented in Subject/Issuer Alternative Names extension.

In which case is it necessary to check the "Subject" field of a certificate?

when there is no SAN extension and industry standard allows cases when proper SAN is not presented. For example, for S/MIME it is recommended to have an rfc822name entry in SAN extension, but if it is missing, it is ok to check Subject field and E attribute in X.500 name.

The followigng logic explains the general concept:

1. Check if SAN extension is presented. Yes: goto 2. No: goto 4.
2. Check is desired name type is presented. Yes: goto 3. No: goto 8.
3. Check if name in desired name type matches your validation requirements (e.g. matches the domain in address bar, such user exists in directory, sender address matches the value in alternative name etc.). Yes: goto 7. No: goto 8.
4. Check if industry standards allow fallback to Subject field. Yes: goto 5. No: goto 8.
5. Check if desired fallback X.500 attribute is presented (CN, E, etc.). Yes: goto 6. No: goto 8.
6. Check if desired RDN your validation requirements (e.g. matches the domain in address bar, such user exists in directory, sender address matches the value in RDN etc.) Yes: goto 7. No: goto 8.
7. Accept certificate. Exit.
8. Reject certificate. Exit.

Some applications allow the absence of SAN extension, e.g. remote desktop (mstsc.exe implementation), S/MIME, VPN, others. Some applications will fail if SAN extension is absent, e.g. HTTPS, MS-PKCA (certificate-based authentication in Active Directory).

Specifically to RADIUS, SAN is not mandatory at least for Microsoft-based clients. However, it is recommended to use SAN whenever possible and use Subject field for descriptive purposes (provide additional informative details about the entity).

Answer 2

There are X.509 certificates in general and there are X.509 certificates as used with HTTPS. For HTTPS just using a common name is long considered obsolete and browsers like Chrome insist on having a subject alternative name. Also, as defined in RFC 6125 and RFC 2818 if a DNS subject alternative name exists the common name should not be checked at all.

Anyway, this is just HTTPS. For different use cases different requirements exist. But I'm not aware of any use case where common name or other parts of the subject should be checked even if a subject alternative name already matches.