2

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.

  • 1
    I can't answer the question of what is in the wild...but it seems to me that the RFC would allow for the contents of the subject field to NOT be reproduced in the subject alternative field. "These identities may be included in addition to or in place of the identity in the subject field of the certificate." – DarkMatter Mar 7 at 16:33
  • As to my understanding, if they are included "in place of the identity in the subject field", that would leave the subject field empty. A few lines further down, the RFC reads "Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used" – Niklas Mar 7 at 17:11
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).

  • Subject should not only be checked if no SAN is present. RFC 2818 and RFC 6125 specifically describe checking the subject if no SAN of type DNS is present. With some protocols even this is not true, i.e. the subject is checked if no matching SAN is present. – Steffen Ullrich Mar 7 at 22:55
  • RFC2818 only talks about HTTPS. RFC6125 is quite new (8 years old) and compatibility requirements slow down the RFC adoption process. And if you want to stay in business, you should maintain compatibility level in your product which may violate the RFC. It took nearly 20 years to enforce RFC2818. I generally agree with you that Subject should be deprecated everywhere, but can't deny the reality. – Crypt32 Mar 8 at 7:23
3

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.

  • I deliberately kept my question general. Do you know about certificates used for wifi, e.g. PEAP, where DNS names are used to identify the radius Server. – Niklas Mar 7 at 17:05
  • @Niklas: There is no general answer. If you have questions about specific use cases of X.509 then please ask a question specific for this use case only (and do not ask such narrowed questions in a comment to an answer to your general question). – Steffen Ullrich Mar 7 at 22:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.