<p>Robert,</p>
<p>Yeah, I've noticed similar issues with subjectAltNames in the past. For keystone, which uses python-httplib2, it currently only works with subjectAltNames if you have the CN repeated otherwise it only thinks the names in the subjectAltNames are the valid hostnames and doesn't even use the CN. I would call that a bug in httplib2. I also don't think httplib2 currently works when IPs are used in the subjectAltName because it only looks at ones with 'DNS' tagged names.</p>

<p>Separate but related, would it be worthwhile making all the clients standardize on a particular SSL http library? Some use python-httplib, python-httplib2, etc...</p>
<p>Nate</p>
<div class="gmail_quote">On Oct 30, 2012 11:47 AM, "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com">robert.clark@hp.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Nate,<br>
<br>
In this context yes, when I (or my esteemed colleague Stuart) mention<br>
CNAME we actually mean the x509 Common Name otherwise referred to as CN.<br>
<br>
You make a good point around subjectAlternativeNames, whenever a<br>
certificate is presented we should check against the CN and the SANs, if<br>
the certificate has SANs.<br>
<br>
There's often confusion as to wether the stated CN of a certificate should<br>
appear in the SANs, this often gets people confused so to get ahead of<br>
that, here's what RFC 5280 Section 4.1.2.6 has to say:<br>
<br>
"""<br>
The subject field identifies the entity associated with the public key<br>
stored in the subject public key field. The subject name MAY be carried in<br>
the subject field and/or the subjectAltName extension.However, there are<br>
some compatibility issues with some TLS implementations, LDAP appears to<br>
require the Common Name to be repeated in the SAN.<br>
"""<br>
<br>
I'm going to add this into the 'standard' grade of SSL, below.<br>
<br>
<br>
<br>
>I presume with your usage of the term CNAME you actually mean the x509<br>
>'common name' or 'CN', not DNS canonical names(CNAMEs)? That does bring<br>
>up the point that we should verify all clients/servers work correctly<br>
>with certificates using subjectAltNames.<br>
>Nate<br>
>On Oct 30, 2012 6:05 AM, <<a href="mailto:stuart.mclaren@hp.com">stuart.mclaren@hp.com</a>> wrote:<br>
><br>
>Hi Rob,<br>
><br>
>For python-glanceclient, which is now using pyopenssl, we are checking<br>
>the server cert, but probably need to also add the 'CNAME is valid for<br>
>the server' check -- I'd be interested if you could confirm this.<br>
><br>
>If so, would adding something like 'match_hostname' from:<br>
><br>
><a href="http://svn.python.org/projects/python/branches/pep-0384/Lib/ssl.py" target="_blank">http://svn.python.org/projects/python/branches/pep-0384/Lib/ssl.py</a><br>
><br>
>into the 'verify_callback' function be appropriate?<br>
><br>
>Also, will openssl check that the certificate is in date by default, or<br>
>should an explicit check for this also be added to the 'verify_callback'?<br>
><br>
>Thanks,<br>
><br>
>-Stuart<br>
><br>
>Date: Tue, 30 Oct 2012 08:31:07 +0000<br>
>From: "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com">robert.clark@hp.com</a>><br>
>To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>Subject: [openstack-dev] [OSSG] SSL Review<br>
>Message-ID: <<a href="mailto:CCB540CA.E6B5%25robert.clark@hp.com">CCB540CA.E6B5%robert.clark@hp.com</a><br>
><mailto:<a href="mailto:CCB540CA.E6B5%2525robert.clark@hp.com">CCB540CA.E6B5%25robert.clark@hp.com</a>>><br>
>Content-Type: text/plain; charset="us-ascii"<br>
><br>
>All,<br>
><br>
>During the summit Bryan highlighted the poor SSL implementations being<br>
>used in various OpenStack clients, with some doing no verification at all.<br>
><br>
>Sadly the state of OpenStack internally (where SSL can be enabled) is<br>
>often little better. I'm going to start a body of work to navigate through<br>
>the code and check exactly what is (or isn't) enabled for each SSL<br>
>interface on offer.<br>
><br>
>I'm planning on checking the ability to execute a wide range of controls<br>
>because we want this 'enhanced' level of security on some particular<br>
>interfaces.<br>
><br>
>(For each interface)<br>
>Fundamental:<br>
>        * Certificate provided is signed by a CA that the client<br>
>recognises as a<br>
>valid trust anchor<br>
>        * Certificate is in-date<br>
>        * No support for known-poor algorithms<br>
>        * Service offering SSL cannot be forced into plaintext<br>
>        * SSLv3 TLSv1 Minimum<br>
><br>
>Standard:<br>
>        * Revocation information is checked (CRL/OCSP)<br>
>        * CN is valid for the server<br>
          * SANs checked for valid match<br>
><br>
>Enhanced:<br>
>        * Support only for strongest available algorithms<br>
>        * X.509v3 Extended Key Usage flags OID verified<br>
>        * Client Certificates have Role-Specific CNAME and verification is<br>
>supported<br>
><br>
>Please comment or add things to the list, also if you've already done some<br>
>similar work please drop me a line so I can include your results.<br>
><br>
>Finally, if you want to help do some of this please feel free!<br>
><br>
>-Rob<br>
><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>