How do Common Names CN and Subject Alternative Names SAN work together

Question

Assuming the Subject Alternative Name  SAN  property of an SSL certificate contains two DNS names  domain tld host domain tld  but the Common Name  CN  is set to only one of both  CN domain tld   Does this setup have a special meaning  or any  dis advantages over setting both CNs  What happens on server-side if the other one  host domain tld  is being requested   Specifically  how does OpenSSL 0 9 8b  handle the given scenario

User · Accepted Answer

This depends on implementation  but the general rule is that the domain is checked against all SANs and the common name  If the domain is found there  then the certificate is ok for connection  RFC 5280  section 4 1 2 6 says  quot The subject name MAY be carried in the subject field and or the subjectAltName extension quot   This means that the domain name must be checked against both SubjectAltName extension and Subject property  namely it s common name parameter  of the certificate  These two places complement each other  and not duplicate it  And SubjectAltName is a proper place to put additional names  such as www domain com or www2 domain com Update  as per RFC 6125  published in 2011  the validator must check SAN first  and if SAN exists  then CN should not be checked  Note that RFC 6125 is relatively recent and there still exist certificates and CAs that issue certificates  which include the  quot main quot  domain name in CN and alternative domain names in SAN  I e  by excluding CN from validation if SAN is present  you can deny some otherwise valid certificate

User · Answer

To be absolutely correct you should put all the names into the SAN field   The CN field should contain a Subject Name not a domain name  but when the Netscape found out this SSL thing  they missed to define its greatest market  Simply there was not certificate field defined for the Server URL   This was solved to put the domain into the CN field  and nowadays usage of the CN field is deprecated  but still widely used  The CN can hold only one domain name   The general rules for this  CN - put here your main URL  for compatibility  SAN - put all your domain here  repeat the CN because its not in right place there  but its used for that     If you found a correct implementation  the answers for your questions will be the followings    Has this setup a special meaning  or any  dis advantages over setting both CNs  You cant set both CNs  because CN can hold only one name  You can make with 2 simple CN certificate instead one CN SAN certificate  but you need 2 IP addresses for this  What happens on server-side if the other one  host domain tld  is being requested  It doesn t matter whats happen on server side    In short  When a browser client connects to this server  then the browser sends encrypted packages  which are encrypted with the public key of the server  Server decrypts the package  and if server can decrypt  then it was encrypted for the server    The server doesn t know anything from the client before decrypt  because only the IP address is not encrypted trough the connection  This is why you need 2 IPs for 2 certificates   Forget SNI  there is too much XP out there still now    On client side the browser gets the CN  then the SAN until all of the are checked   If one of the names matches for the site  then the URL verification was done by the browser    im not talking on the certificate verification  of course a lot of ocsp  crl  aia request and answers travels on the net every time

User · Answer

CABForum Baseline Requirements  I see no one has mentioned the section in the Baseline Requirements yet  I feel they are important   Q  SSL - How do Common Names  CN  and Subject Alternative Names  SAN  work together  A  Not at all  If there are SANs  then CN can be ignored  -- At least if the software that does the checking adheres very strictly to the CABForum s Baseline Requirements    So this means I can t answer the  Edit  to your question  Only the original question    CABForum Baseline Requirements  v  1 2 5  as of 2 April 2015   page 9-10      9 2 2 Subject Distinguished Name Fields   a  Subject Common Name Field   Certificate Field  subject commonName  OID 2 5 4 3    Required Optional  Deprecated  Discouraged  but not prohibited    Contents  If present  this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate   s subjectAltName extension  see Section 9 2 1      EDIT  Links from  Bruno s comment  RFC 2818  HTTP Over TLS  2000  Section 3 1  Server Identity      If a subjectAltName extension of type dNSName is present  that MUST      be used as the identity  Otherwise  the  most specific  Common Name      field in the Subject field of the certificate MUST be used  Although      the use of the Common Name is existing practice  it is deprecated and      Certification Authorities are encouraged to use the dNSName instead    RFC 6125  Representation and Verification of Domain-Based Application Service  Identity within Internet Public Key Infrastructure Using X 509  PKIX       Certificates in the Context of Transport Layer Security  TLS   2011  Section 6 4 4  Checking of Common Names            if and only if the presented identifiers do not include a      DNS-ID  SRV-ID  URI-ID  or any application-specific identifier types      supported by the client  then the client MAY as a last resort check      for a string whose form matches that of a fully qualified DNS domain      name in a Common Name field of the subject field  i e   a CN-ID

[ssl] How do Common Names (CN) and Subject Alternative Names (SAN) work together?

Examples related to ssl

Examples related to https

Examples related to ssl-certificate