What is the Subject Names / Subject alternative names and how do they differ from each other?
Specially the template below "subject name" tab. What does that change in the normal certificate request other than that there is an additional step to put information in the subject tab while enrolling for a certificate.
What is the role of Subject Names (SN) / Subject Alternative Names (SAN) in Microsoft Public Key Infrastructure (PKI)? How are SANs used, and what scenarios benefit from their inclusion in certificates?
Best Answer
A certificate binds a public key to a subject. The subject of a certificate is the details of the holder. Your question is like asking "What is the purpose of a Name on a passport?".
Both the Subject field and the Subject Alternative Name (SAN) extension are simply two ways of identifying the subject, or the holder.
Originally, in version 1 certificates, there was no concept of certificate extensions (such as Subject Alternative Names and Basic Constraints) and the only way to define the certificate's subject was with the Subject field. This expects a Distinguished Name, which is defined in X.500 and consists of elements such as Common Name (CN), Organisation (O), and Country (C). This works reasonably well for addresses such as corporate address or even personal addresses, but not so well for DNS systems - there is no Hostname element in X.500 AFAIK. If you look at this site's certificate, you'll see that the issuer is:
CN = E1, O = Let's Encrypt, C = US- not unreasonable.As part of the certificate verification process, browsers expect the hostname element of the URL entered in their address bar to be matched with the subject of the server's certificate. Browser vendors expected the FQDN of a host to be entered in the certificate as the Common Name (look at this site's certificate and you'll see that the CN is
serverfault.com).However, entering the FQDN of a server in the CN is a bit of a hack - what if we enter the server's IP address into the browser instead? Also, what if the subject of a certificate is identified by something else, such as the UPN for a client certificate in Windows? Do we also squeeze that into the CN, or add it as an email element? This could get messy and open to errors.
Version 3 certificates introduced the concept of extensions, and one of those extensions is Subject Alternative Name (SAN). This allows more detailed definition of the type of the name. For example, it supports DNS, IP addresses, email addresses, URLs and more. Clients therefore don't have to guess what the subject refers to. The SAN can also contain multiple entries, so you could have one for the server's FQDN and another for its IP address, so entering either in a browser would be considered valid.
These days, browsers don't even look at the Subject field, and expect the server's subject (DNS, IP address etc.) to be in the SAN.
RFC 5280 would be a good bedtime read if you want more details of their meaning, and RFC 2818 Section 3.1 has a simple explanation of how they're used in the context of HTTPS. For a more generic discussion of matching subject names, consider RFC 6125 (or look at it simply for it's snappy title :-))