Bug #196

Common Name is only validated if no Subject Alternative Name is present

Added by mei se about 5 years ago. Updated about 5 years ago.

Status:ConfirmedStart date:04/09/2014
Priority:NormalDue date:
Assignee:-% Done:


Category:-Spent time:-
Target version:-


There are certificates in the wild with Subject Alternative Names defined but without a valid general DNS name set. For example something like this:

        Subject: C=DE, …, CN=foo.bar.example.com/emailAddress=operator@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
    Signature Algorithm: …

Such certificates are currently rejected even if the Common Name would be valid.

matches_subject_alternative_name function in ssl_hostname_validation.c returns only SSL_HOSTNAME_NO_SAN_PRESENT (case one), SSL_HOSTNAME_MATCH_NOT_FOUND (case two) or a positive match we don't have to worry about, because we have found the hostname.

So if case one is returned, everything is fine, because line 274 is true and matches_common_name is called in the next step. But if case two is returned, witch means no hostname matched in Subject Alternative Names, matches_common_name is not called and the certificate is rejected.

I would suggest the following patch:

Index: libsylph/ssl_hostname_validation.c
--- libsylph/ssl_hostname_validation.c    (revision 3380)
+++ libsylph/ssl_hostname_validation.c    (working copy)
@@ -271,7 +271,7 @@

     // First try the Subject Alternative Names extension
     result = matches_subject_alternative_name(hostname, server_cert);
-    if (result == SSL_HOSTNAME_NO_SAN_PRESENT) {
+       if ((result == SSL_HOSTNAME_NO_SAN_PRESENT) || (result == SSL_HOSTNAME_MATCH_NOT_FOUND)) {
         // Extension was not found: try the Common Name
         result = matches_common_name(hostname, server_cert);


#1 Updated by Hiroyuki Yamamoto about 5 years ago

  • Status changed from New to Confirmed

The patch does not differentiate "SAN without DNSName" from "SAN with valid DNSNames but there is no match".
At the latter case, Common Name should not be used, according to RFC 6125.

Also available in: Atom PDF