[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-users
Subject: [openssl-users] Why is CARoot handling different in Servers verifying Clients versus Clients verifyi
From: Simon Edwards <simon.edwards301 () gmail ! com>
Date: 2018-04-27 16:29:09
Message-ID: CAEq1Smaa1zcV0TXG81BL3jxOCJSUDxLWWNAf-5f=GTWGs8dMCg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello,
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.
I wonder of anyone can shed light on why OpenSSL treats the two CARoot file
collections used in Servers and Clients differently?
Is it simply for performance purposes?
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.
This issue concerns the handling of multiple types of CARoot and
Intermediate Certs held in a single PEM file.
I'm using 1.0.2 for debugging, but the following code is also in 1.1.0 and
1.1.1.
All of the following takes place in ssl/ssl_certs.c.
For Clients the CARoot collection's cert store generator works as follows:
*SSL_CTX_load_verify_locations*() calls *X509_load_cert_crl_file*() to
load a file into a ctx based store.
In my test case all 6 CARoot and Intermediate certs are loaded.
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.
*SSL_load_client_CA_file*() is the Server's CARoot cert collection
generator
This *SSL_load_client_CA_file*() 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.
This check is done using *X509_get_subject_name*() and the comparison is
done using *sk_X509_NAME_find*()
In my test case only 5 of the 6 certs are loaded. I think this is wrong.
The same CARoot collection PEM file is being used in both cases.
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.
All the certs involved are generated for the test scenario using OpenSSL.
Not commercial certs.
4 levels of intermediate RSA certs.
The RSA CARoot cert
The ECDSA CARoot cert
Servers and Clients are generated at various levels of the intermediate
collection. Plus directly by the ECDSA CAroot.
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.
Depending upon the order of the content in the CARoots PEM file the
rejected Clients will change.
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.
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.
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.
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.
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?
I'm also aware of this which may have introduced the issue:
http://openssl.6102.n7.nabble.com/openssl-org-3495-Enhance-SSL-load-client-CA-file-td52977.html
Am I missing something fundamental here?
Is the Server side verification supposed to work for multiple signature
types when they are identifying the same CARoot entities?
If so, I suggest that the sig' type not being checked alongside the
SubjectName when checking for duplicates is a bug.
Simon Edwards
[Attachment #5 (text/html)]
<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-fi \
le-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>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic