Thanks Dave. That part of it is clear now. 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. 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. 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? 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. Is my understanding correct? Regds, Ashok On Wed, Dec 21, 2011 at 8:46 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Tuesday, 20 December, 2011 04:16 > > > What will be the recommendation from the open source community for > > supporting the following scenario in a openSSL based client/server > application: > > > The certificates involved: > > old CA certificate of the CA authority(root) > > new CA certificate of the CA authority(root) > > Server's end entity certificate issued by the old CA certificate, > > Server's end entity certificate issued by the new CA certificate > > Client's end entity certificate issued by the new CA certificate > > SSL_VERIFY_PEER set to TRUE. i.e., Client verifies server > certificate > > and server verifies client certificate. > > Note: in client SSL_VERIFY_PEER fails if server cert doesn't verify; > in server it requests cert from client, and fails if client cert > is provided and doesn't verify, but succeeds if client doesn't provide > cert. To fail in the latter case, add SSL_VERIFY_FAIL_IF_NO_PEER_CERT. > Or else after the handshake explicitly check SSL_get_peer_certificate > and if missing do some appropriate error. > > 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. > > > Scenario: > > Now, the client in its SSL_load_verify_locations() will need to > > load both the old CA certificate as well as the new CA certificate. > <snip> > > So, now it is like loading multiple trust anchors in a single file. > > So here, is it better to use the CAFile option to load [] a single > > concatenated PEM file(CAFile)) or is it better to use the CAPath option > > for this scenario: [with hashnames] > > Either. Whichever you or your users prefer. > > Usual caveat: the CApath hash changed between 0.9.8 and 1.0.0. > Make sure to use the correct one for the code you run. > > Rarer caveat: CApath can be updated while a program using it is > running; generally this only matters for a (very) long-running > server. CAfile ignores updates, unless you re-load explicitly. > > > Basically we wanted to know if CAFile would give a problem > > in case of multiple trust anchor certificates put together? > > No problem; that's quite normal. The truststore, either CAfile > or CApath or a combination, exists to contain all trusted roots > and usually (though not always) there are multiple roots. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
