Sorry for spamming, a small correction here.
Scenario 3 is also failing and not successful as indicated in my earlier
email.
*Scenario 3:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
Result: Connection failure.
Regds,
Ashok
On Tue, Dec 27, 2011 at 4:50 PM, Ashok C <ash....@gmail.com> wrote:
> 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
>>
>
>
