RE: Supporting oldwithold, newwithnew CA certificates Reg.
> From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > Sent: Tuesday, 27 December, 2011 06:20 > 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. > > 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. The last time I tried a rollover with the same name, it did fail for me, but that was quite a few years ago. Possibly something has changed since. I don't have time to retest now. If it works for you fine. > 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. Yes. There are several good reasons for multiple certs (and keys). 1. (Really) different CAs e.g. server A accepts only certs from a private/internal A-CA that enforces company-A rules about which clients get certs, but client also connects to server B in a different company which understandably won't rely on A-CA and demands a "public" CA or even a similar but different private/internal B-CA. Similarly but less often a server may use an internal-CA cert for internal clients who know about and trust that CA, but a public one for other clients. 2. Different algorithms: server has one key-and-cert for RSA suites and different one for DSS (DSA) suites and maybe a third for ECDSA, and client similarly. In years past this was sometimes a political issue: systems in or connected to the US government were required to use DSA and not RSA, and some people in other places who didn't like the US government would use RSA but not DSA (including places where the US-issued patent on RSA wasn't enforced). Today this has died down and pretty much everybody trusts everybody at least for the cryptography, although there are still some places where ECDSA (and ECDH) aren't yet implemented versus others which insist on them because of bandwidth or power concerns e.g. mobile devices. 3. Rollover/replacement much like your scenario; sometimes it isn't possible to "cut" a new CA (generation) all at once and there is a transition period where e.g. client needs new-cert for server A but old-cert for server B which hasn't been updated yet. 4. Or you can do it just because you want to; the protocol only requires *a* server cert (unless anon) and *a* client cert (if client-auth used) that work, it doesn't care what others exist. > 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? The original (SSL) protocol didn't provide for this beyond the algorithm selection inherent in the Client/ServerHello exchange. OpenSSL server can be configured with all three algorithms and will use whichever one (first) agrees with the client request; I'm not sure if OpenSSL client can offer more than one (I have never needed to try that). TLS extensions (RFC3546 in 2003, but optional in OpenSSL until about 2008 as I recall) adds among other features: - ClientHello can specify "logical" server name; in particular for HTTPS this is the domain name from the URL, useful in cases where a single actual server supports multiple "virtual" hosts. - ClientHello can specify "trusted CA keys", either as a CA DN or several other methods. - EC (RFC4492 in 2006) adds extensions to limit the curves and formats the client supports, which if the server disagrees should result in not selecting an EC suite (and if no other suites are shared, handshake failure). > 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? For restricting cipher algorithms, *_set_cipher_list. For the server-name extension, SSL_set_tlsext_host_name in client. In server you provide a callback, with arg, to handle reception. OpenSSL apparently does not implement the explicit "CA keys" extension, and I don't know if anyone else does either. I haven't tracked through completely, but I believe OpenSSL always uses the correct values for EC curves and formats, i.e. OpenSSL supports what it supports and you don't change it. (You can of course choose to not use EC suites at all.) ___
Re: Supporting oldwithold, newwithnew CA certificates Reg.
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 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 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-a
Re: Supporting oldwithold, newwithnew CA certificates Reg.
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 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 > Clie
RE: Supporting oldwithold, newwithnew CA certificates Reg.
> 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Supporting oldwithold, newwithnew CA certificates Reg.
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 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. > > > 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 Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Supporting oldwithold, newwithnew CA certificates Reg.
> 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. > 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Supporting oldwithold, newwithnew CA certificates Reg.
Hi, 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. *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. This will be to make sure that the connection is successful when the server sends the new end entity certificate or even when the server sends its old EE certificate(No CRLs involved as of now). 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 the CA certificates for verification(putting both the old CA certificate + new CA certificate into a single concatenated PEM file(CAFile)) or is it better to use the CAPath option for this scenario: Generating hashes for old CA certificate and new CA certificate separately and putting them into one common directory(CAPath)? Basically we wanted to know if CAFile would give a problem in case of multiple trust anchor certificates put together? Regds, Ashok
