<p>I presume with your usage of the term CNAME you actually mean the x509 'common name' or 'CN', not DNS canonical names(CNAMEs)? That does bring up the point that we should verify all clients/servers work correctly with certificates using subjectAltNames.</p>
<p>Nate </p>
<div class="gmail_quote">On Oct 30, 2012 6:05 AM, <<a href="mailto:stuart.mclaren@hp.com">stuart.mclaren@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 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/<u></u>projects/python/branches/pep-<u></u>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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Tue, 30 Oct 2012 08:31:07 +0000<br>
From: "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com" target="_blank">robert.clark@hp.com</a>><br>
To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>><br>
Subject: [openstack-dev] [OSSG] SSL Review<br>
Message-ID: <<a href="mailto:CCB540CA.E6B5%25robert.clark@hp.com" target="_blank">CCB540CA.E6B5%robert.clark@<u></u>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 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>
* CNAME is valid for the server<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>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>