When connecting to a SSL server, the certificate verification failed if
it has a subjectAltName extension without any dNSName entry inside: it
should fallback to the Common Name.

Example:

    >>> cert = conn.getpeercert()
    >>> cert
    {'notAfter': 'May 15 14:31:42 2011 GMT',
     'subject': ((('countryName', u'FR'),),
                 (('stateOrProvinceName', u'Ile-de-France'),),
                 (('localityName', u'Paris'),),
                 (('organizationName', 'xxx'),),
                 (('organizationalUnitName', 'xxx'),),
                 (('commonName', 'foobar.corp'),),
                 (('emailAddress', u'test@test.net'),)),
     'subjectAltName': (('email', text@test.net'),)}


This certificate is valid according to RFC 2818:

    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.

Even if the use of CommonName is deprecated, we should not break
existing systems.

Current revision of Lib/ssl.py :

    108 def match_hostname(cert, hostname):
    ...
    119     san = cert.get('subjectAltName', ())
    120     for key, value in san:
    121         if key == 'DNS':
    122             if _dnsname_to_pat(value).match(hostname):
    123                 return
    124             dnsnames.append(value)
    125     if not san:
    126         # The subject is only checked when subjectAltName is empty
    127         for sub in cert.get('subject', ()):
    128             for key, value in sub:
    129                 # XXX according to RFC 2818, the most specific Common Name
    130                 # must be used.
    131                 if key == 'commonName':
    132                     if _dnsname_to_pat(value).match(hostname):
    133                         return
    134                     dnsnames.append(value)
    ...

Proposed patch is:


diff -r 513f6dfd3173 Lib/ssl.py
--- a/Lib/ssl.py        Sun May 01 20:24:59 2011 -0500
+++ b/Lib/ssl.py        Mon May 02 11:16:46 2011 +0200
@@ -122,8 +122,9 @@
             if _dnsname_to_pat(value).match(hostname):
                 return
             dnsnames.append(value)
- if not san:
- # The subject is only checked when subjectAltName is empty
+ if not san and not dnsnames:
+ # The subject is only checked when there is no dNSName entry
+ # in subjectAltName
  for sub in cert.get('subject', ()):
      for key, value in sub:
          # XXX according to RFC 2818, the most specific Common Name

Are you sure about "if not san and not dnsnames"? It is even more restrictive than the currently condition. "if not dnsnames" looks like it would fit the bill better.

Also, better if you can provide a complete patch, including additional test(s) in Lib/test/test_ssl.py.
(see http://docs.python.org/devguide/runtests.html if you want information about running/writing tests)

P.S.: if you're really right ('have those RFC's, but didn't read
them yet), you could also open an issue for Mercurial at
http://mercurial.selenic.com/bts - i think those guys do the very
same.

Thanks, Steffen!

Hello Antoine, Steffen,

You are absolutely right about removing the 'not san' part. Here is the
new patch, with tests :

diff -r c22d5b37f6a4 Lib/ssl.py
--- a/Lib/ssl.py        Fri May 06 09:31:02 2011 +0300
+++ b/Lib/ssl.py        Fri May 06 12:47:14 2011 +0200
@@ -122,8 +122,9 @@
             if _dnsname_to_pat(value).match(hostname):
                 return
             dnsnames.append(value)
-    if not san:
-        # The subject is only checked when subjectAltName is empty
+    if not dnsnames:
+        # The subject is only checked when there is no dNSName entry
+        # in subjectAltName
         for sub in cert.get('subject', ()):
             for key, value in sub:
                 # XXX according to RFC 2818, the most specific Common Name
diff -r c22d5b37f6a4 Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py      Fri May 06 09:31:02 2011 +0300
+++ b/Lib/test/test_ssl.py      Fri May 06 12:47:14 2011 +0200
@@ -277,6 +277,24 @@
                             (('organizationName', 'Google Inc'),))}
         fail(cert, 'mail.google.com')
 
+        # No DNS entry in subjectAltName but a commonName
+        cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT',
+                'subject': ((('countryName', 'US'),),
+                            (('stateOrProvinceName', 'California'),),
+                            (('localityName', 'Mountain View'),),
+                            (('commonName', 'mail.google.com'),)),
+                'subjectAltName': (('othername', 'blabla'), )}
+        ok(cert, 'mail.google.com')
+
+        # No DNS entry subjectAltName and no commonName
+        cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT',
+                'subject': ((('countryName', 'US'),),
+                            (('stateOrProvinceName', 'California'),),
+                            (('localityName', 'Mountain View'),),
+                            (('organizationName', 'Google Inc'),)),
+                'subjectAltName': (('othername', 'blabla'),)}
+        fail(cert, 'google.com')
+
         # Empty cert / no cert
         self.assertRaises(ValueError, ssl.match_hostname, None, 'example.com')
         self.assertRaises(ValueError, ssl.match_hostname, {}, 'example.com')


Steffen, I will submit a bug report to Mercurial as soon as this patch is expected to be integrate in py3k.

New changeset d4c2a99d1bad by Antoine Pitrou in branch '3.2':
Issue #12000: When a SSL certificate has a subjectAltName without any
http://hg.python.org/cpython/rev/d4c2a99d1bad

New changeset 1b37827984ba by Antoine Pitrou in branch 'default':
Issue #12000: When a SSL certificate has a subjectAltName without any
http://hg.python.org/cpython/rev/1b37827984ba

Patch committed in 3.2 and 3.x, thank you!

In my opinion the RFCs are a bit unclear about how iPAddress subjectAltNames should be handled. (I also don't know if Python currently do the right thing by accepting and matching IP addresses if specified in commonName.)

Until now Python failed to the safe side by not matching on subjectAltName iPAddress but also not falling back to commonName if they were specified. AFAICS, with this change it is possible to create strange certificates that Python would accept when an IP address matched commonName but other implementations would reject because of iPAddress mismatch.

That is probably not a real problem, but I wanted to point it out as the biggest issue I could find with this fix. Nice catch.

We could perhaps add IP addresses to dnsnames even though we don't match on them.

Hello Mads

> Until now Python failed to the safe side by not matching on 
> subjectAltName iPAddress but also not falling back to commonName
> if they were specified. AFAICS, with this change it is possible to 
> create strange certificates that Python would accept when an IP 
> address matched commonName but other implementations would reject 
> because of iPAddress mismatch.

Good point! But I think we already have this issue with a certificate 
like this one:

cert = { 'subject': ((('commonName', '192.168.1.1'),),)}
ok(cert, '192.168.1.1')

Do you think this test should fail?

Nicolas Bareil wrote, On 05/07/2011 09:48 AM:
> Do you think this test should fail?

Until now I have considered this behaviour OK but undocumented and 
officially unsupported in Python. One (the best?) reason for considering 
it OK is that if someone (intentionally or not) trusts a certificate 
that happens to have the textual representation of an IP address in 
commonName then there is no doubt what the intention with that is. This 
case is thus within what i considered secure behaviour.

But the more I look at it the more convinced I get that this test should 
fail. RFC 2818 mentions subjectAltName iPAddress as a "must" for IP 
addresses - even though it only uses a lower-case and thus 
perhaps-not-necessarily-authoritative "must". But the best argument 
against IP in commonName is that it isn't mentioned anywhere, and when 
it isn't explicitly permitted we should consider it forbidden.

A consequence of that is that my previous concern is invalid. There is 
no reason the presence of a subjectAltName iPAddress should prevent 
fallback from dNSName to commonName.