<div dir="ltr"><div><br>Hello, <br><br>Its been about 12 years since my last post here. So I apologize in advance if I trample anyone/anything due to any changes in etiquette since back then.<br><br><br>I wonder of anyone can shed light on why OpenSSL treats the two CARoot file collections used in Servers and Clients differently?<br><br></div><div>Is it simply for performance purposes?<br><br><br></div><div>The reason I ask is that I have found a difference in behaviour between the two implementations, which on the surface at least looks like a bug - or at least a missed piece of implementation. It has had an unwanted effect in my testing setup.<br><br><br></div><div>This issue concerns the handling of multiple types of CARoot and Intermediate Certs held in a single PEM file.<br></div><div><br></div><div>I'm using 1.0.2 for debugging, but the following code is also in 1.1.0 and 1.1.1.<br></div><div><br><br></div><div>All of the following takes place in ssl/ssl_certs.c.<br><br><br></div><div>For Clients the CARoot collection's cert store generator
works as follows:<br></div><div><br></div><div> <b>SSL_CTX_load_verify_locations</b>() calls <b>X509_load_cert_crl_file</b>() to load a file into a ctx based store.<br><br>In my test case all 6 CARoot and Intermediate certs are loaded.<br><br><br>The Server's side however takes a completely different route to do a very similar task. It also stores the results in a different place.<br><br> <b>SSL_load_client_CA_file</b>() is the Server's CARoot cert collection generator <br><br></div><div>This
<b>SSL_load_client_CA_file</b>()
checks each new cert being loaded against hashes of existing Subject_Name entries of certificates already loaded into the stack of certs and discards duplicates.<br><br></div><div> This check is done using <b>X509_get_subject_name</b>() and the comparison is done using <b>sk_X509_NAME_find</b>()<br></div><div><br>In my test case only 5 of the 6 certs are loaded. I think this is wrong.<br><br><br><br></div><div>The same CARoot collection PEM file is being used in both cases.<br><br>
<div><br></div><div>My problem is triggered because I am testing a dual RSA/ECDSA
implementation on a single Server endpoint, and I also have ECDSA and RSA
identified clients.</div>
<br></div><div>All the certs involved are generated for the test scenario using OpenSSL. Not commercial certs.<br></div><div><br> 4 levels of intermediate RSA certs.<br></div><div> The RSA CARoot cert<br></div><div> The ECDSA CARoot cert<br></div><div><br><br></div><div>Servers and Clients are generated at various levels of the intermediate collection. Plus directly by the ECDSA CAroot.<br><br><br><br></div><div>The issue is that all unidentified/un-certified Clients can connect to Servers, but Servers will reject some certified Clients when asked to verify them. <br><br>Depending upon the order of the content in the CARoots PEM file the rejected Clients will change.<br><br></div><div>The problem is that the CARoot cert is available in both signature types - but the rest of the identification information in the two certificates is pretty much the same content. The time stamps change of course, but its identifying the same CA. Just using different signature types.<br><br></div><div>Because of the Server side test of the SubjectName, the subject name of whichever cert is second in the PEM file will be compared with the previously loaded certificate and ignored. This preventing Clients identified by that CA from being verified.<br><br>This looks like a bug in OpenSSL based upon the assumption that the SubjectName hash is enough of a unique identifier. Which was probably true back when all certs were RSA certs. Nothing else needed checking.<br><br></div><div>Surely a more accurate approach today would be to combine the SubjectName with the certificate signature type when creating the hash values. Or to simply do what the client side does and avoid duplication checks - now I do know that the latter is not a sensible action for performance reasons.<br><br></div><br><div><br>BTW I realize that simply changing the ID to "CA Name RSA" and CA Name ECDSA" would most likely solve this for my test case. However I don't think I should need to do this. Or is this a miss-understanding on my part?<br><br></div><div>I'm also aware of this which may have introduced the issue: <br> <a href="http://openssl.6102.n7.nabble.com/openssl-org-3495-Enhance-SSL-load-client-CA-file-td52977.html">http://openssl.6102.n7.nabble.com/openssl-org-3495-Enhance-SSL-load-client-CA-file-td52977.html</a><br><br><br></div><div>
<div>Am I missing something fundamental here? <br><br></div><div>Is the Server side verification supposed to work for multiple signature types when they are identifying the same CARoot entities?<br><br></div><div>If so, I suggest that the sig' type not being checked alongside the SubjectName when checking for duplicates is a bug.<br><br><br></div><div>Simon Edwards<br></div><div><br></div>
<br><br><br><br><br></div></div>