lucky-geqian / httplib2

Automatically exported from code.google.com/p/httplib2
0 stars 0 forks source link

Failed to retrieve the certificate if it has 'subjectAltName' but no 'dns' #208

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Some certificates have subjectAltName, but no 'dns' attribute associated with 
it. Thus it failed to get the host and produces error:
"Server presented certificate that does not match host <HostName>

What steps will reproduce the problem?
1. Find some certificate with subjectAltName, but dns is missing
2. Try to connect with this certificate
3.

What is the expected output? 
Connection succeed without error.

What do you see instead?
Failed to find host information from certification, thus following error is 
shown:
error: Server presented certificate that does not match host

What version of the product are you using? On what operating system?
python-httplib2-0.7.4

Please provide any additional information below.
Proposed patch attached.

Original issue reported on code.google.com by dingyichen on 3 May 2012 at 7:13

Attachments:

GoogleCodeExporter commented 8 years ago
The patch fixes the problem for me.

Original comment by sean.flanigan@gmail.com on 4 May 2012 at 4:30

GoogleCodeExporter commented 8 years ago
One objection about the patch

In case that subjectAltName has a 'dns' element with only one name the output 
is returned as a string and then the validation fails when comparing with the 
hostname.

Original comment by josecast...@gmail.com on 8 Jun 2012 at 1:23

GoogleCodeExporter commented 8 years ago
> One objection about the patch
> 
> In case that subjectAltName has a 'dns' element with only one name the output 
is returned as a string and then the validation fails when comparing with the 
hostname.

The function's comment says the function returns a list, so the single entry 
should be returned in a list.

However, there's another problem: if the subjectAltName entry has *multiple* 
dns entries, only the first hostname is returned.

I have a script that uses the Instapaper (http://www.instapaper.com) API. 
Here's the error when connecting:

httplib2.CertificateHostnameMismatch: Server presented certificate that does 
not match host www.instapaper.com: {'notAfter': 'Apr 13 00:29:37 2017 GMT', 
'subjectAltName': (('DNS', 'www.instapaper.com'), ('DNS', 'instapaper.com')), 
'subject': ((('serialNumber', u'kFgvILuOXBY2A3gz3DTbhKsV8Tm6x8T7'),), 
(('countryName', u'US'),), (('organizationName', u'www.instapaper.com'),), 
(('organizationalUnitName', u'GT72497635'),), (('organizationalUnitName', u'See 
www.rapidssl.com/resources/cps (c)11'),), (('organizationalUnitName', u'Domain 
Control Validated - RapidSSL(R)'),), (('commonName', u'www.instapaper.com'),))}

The attached patch fixes this for me.

Original comment by richardfearn on 15 Jun 2012 at 8:23

Attachments:

GoogleCodeExporter commented 8 years ago
Your patch works for me

> The function's comment says the function returns a list, so the single entry 
should be returned in a list.

As an extra comment 

{'notAfter': 'Jun  7 06:45:20 2013 GMT', 'subjectAltName': (('DNS', 
'keystonessl.cern.ch'),), 'subject': ((('domainComponent', u'ch'),), 
(('domainComponent', u'cern'),), (('organizationalUnitName', u'computers'),), 
(('commonName', u'keystonessl.cern.ch'),))}

if 'subjectAltName' in cert:
    for x in cert['subjectAltName']:
        if x[0].lower() == 'dns':
             return x[1]  <----- returns 'keystonessl.cern.ch' instead of ('keystonessl.cern.ch')

Original comment by josecast...@gmail.com on 21 Jun 2012 at 9:08

GoogleCodeExporter commented 8 years ago
I can also confirm that richardfern's patch work for the reproducer provide by 
the bug reporter.

Original comment by dingyichen on 22 Jun 2012 at 5:47

GoogleCodeExporter commented 8 years ago
The patch that ricardfearn supplied still fail if it has subjectAltName but has 
other field instead of 'DNS', such as email, URI, and IP, which are all valid 
for RFC 2459.

Thus I supply a new patch based on richardfearn's.

Original comment by dingyichen on 30 Jul 2012 at 3:54

Attachments: