Thanks Dave. But regarding this: >>Important note: make sure the old and new root certs have different names. (Same for intermediate CAs, which your example doesn't have.) OpenSSL looks-up using Issuer name only. It *verifies* AKI if present, and of course uses subjectkey to verify child and thus gets an error if lookup found wrong parent. But it looks-up only by name, so if old and new certs have the same name OpenSSL may use the wrong one. >>
I actually tested this particular scenario in my testbed and found that it
is not necessary that the old and new CA certs have different names.
I generated an oldcacert.pem and and oldcakey.pem using which I signed my
oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem
using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem
had the same subject/issuer names. The scenarios I tested go below:
*Scenario 1:*
openssl s_server -cert oldeecert.pem -key oldeekey.pem
openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
Result: Connection successful
*Scenario 2:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/newcacert.pem
Result:Connection successful
*Scenario 3:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
Result: Connection successful
*
Scenario 4:*
openssl s_server -cert oldeecert.pem -key oldeekey.pem
openssl s_client -CAfile /root/certs/cacerts/newcacert.pem
Result: Connection Failure
Now, I put both oldcacert.pem and newcacert.pem into a single combined.pem,
the first certificate being oldcacert.pem and the second certificate being
newcacert.pem.
*Scenario 5:*
openssl s_server -cert oldeecert.pem -key oldeekey.pem
openssl s_client -CAfile /root/certs/cacerts/combined.pem
Result: Connection Successful
*Scenario 6:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/combined.pem
Result: Connection Successful
So now, this means that the openSSL verification check does not stop with
the first matching issuer certificate alone right? Because if that was the
case, Scenario 6 should have failed.
I have attached my certificates for reference. All are v3 certificates.
I am using openssl version "openssl-0.9.8g".
One more clarification:
>>If OpenSSL client has cert-and-pkey configured and receives CertReq,
it sends that cert regardless of any CAlist the server asked for;
that cert may be accepted or not depending on the server. And if
callback or engine is used it appears (but I haven't tested) that
can similarly select any cert regardless of what the server asked.
>>
Are you indicating here that the client can have multiple end entity
certificates? Till now I had the assumption that the server/client can have
only a single end entity certificate. Also, if the server can ask client to
send selective certificates, wouldn't it be applicable that the client also
can request the server for specific certificates? Are there separate
openSSL APIs for this or we have to use the same family of
ssl_ctx_set_client* family of APIs for this purpose also?
Regds,
Ashok
On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson <dthomp...@prinpay.com>wrote:
> > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
> > Sent: Thursday, 22 December, 2011 10:55
>
> > Another doubt I have is about the SSL_CTX_set_client_ca_list
> > and the SSL_get_client_ca_list.
>
> > I understand that the set method is called by the server to
> > set the list of CA names that it actually expects from the client.
> > And the client calls ssl_get_client_ca_list to get these names and
> > send the appropriate CA certificates in its chain for verification
> > to the server.
>
> Nit: case is important in C identifiers. Skipping that:
>
> Not quite. Server can call _set_client_CA_list to set the CA names it
> *asks for* from the client; server still uses _load_verify_locations
> to verify the cert received if any. OpenSSL allows you to make these
> different: e.g. ask the client for CA1 and CA2, but verify only CA2,
> or CA2 and CA3, or only CA3. I've never seen a good use for this.
>
> OpenSSL client calls the client_cert callback or engine only if
> you did *not* set a cert-and-private-key before the handshake.
> Callback or engine can look at the CAlist specified by the server
> if any (see next) to choose what cert-and-private-key to use.
> For callback it apparently needs to call SSL_get_client_CA_list,
> for engine this value is passed separately.
>
> > I assume that both these methods are actually optional even when
> SSL_VERIFY_PEER
> > flag is set to true, i.e., client verifies server and server
> verifies client.
>
> If OpenSSL server sets VERIFY_PEER but doesn't _set_client_CA_list,
> it sends CertReq with an empty CA list. According to the RFCs
> in this case "the client MAY send any certificate of the appropriate
> ClientCertificateType, unless there is some external arrangement to
> the contrary." If the client is configured or operated to send a cert
> that the server accepts (using _load_verify_locations) it's okay.
>
> If OpenSSL client has cert-and-pkey configured and receives CertReq,
> it sends that cert regardless of any CAlist the server asked for;
> that cert may be accepted or not depending on the server. And if
> callback or engine is used it appears (but I haven't tested) that
> can similarly select any cert regardless of what the server asked.
>
> > I set up my server and client without these two methods and things
> > still go fine. What would be the exact purpose of this family of methods?
>
> See above. As long as the client is configured with or selects a cert
> acceptable to the server it's okay, regardless of what if anything
> the server asked for in CertReq.
>
> > What I understand from my reading is that the SSL_CTX_set_client_CA_list
> > function is only needed by server applications that verify the identity
> > of remote client applications when SSL sessions are started and that if
> > the SSL_CTX_set_client_CA_list function is not used and you request a
> > client certificate, the list of CA names that get passed to the client
> > application are the CAs from the SSL_CTX_load_verify_locations function.
>
> No. By default the server asks for an empty CAlist; see above.
> If you want to ask the client for the same CAs you will use to verify,
> which for many clients is usually a good idea, you must explicitly call
> _set_client_CA_list (or _add_client_CA) with the same CA certs as are
> in your truststore. That is easier to do with CAfile format, which
> could be a factor in your decision there at least for server.
>
> You may be confused by the fact (I was once) that commandline s_server
> uses -CAfile *also* for _set_client_CA_list. But that's specific code
> in that program, not a feature of OpenSSL in general.
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
certs.rar
Description: application/rar
