Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, But even with that done/fixed in my test environment I DO get verify error 24 invalid CA cert depth 1 (my only intermediate). Is that what you're getting? If so, it looks like maybe the 'purpose' checks have been made stricter since the last time I did this in test, where I have V1/noextension certs. I can't set up a test with real(er) (CA)certs immediately. If you have V1 or otherwise 'substandard' CA certs, you might try enhancing those. Yes, I was getting the same error. And after using v3 certificates, the error did not appear again and my client-server app is working well with the multi-level configuration. Thanks a lot for your patient help in this regard. Regds, Ashok On Sat, Dec 3, 2011 at 4:17 AM, Dave Thompson dthomp...@prinpay.com wrote: From: Ashok C [mailto:ash@gmail.com] Sent: Friday, 02 December, 2011 00:11 Keeping the things you have mentioned in mind, this is how it goes. In server side, EE key is loaded using SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, eepemfile,SSL_FILETYPE_PEM); And the intermediate certificate chain is loaded using SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain contains intermediate CA certs without the rootCA. In client side, rootCA is loaded using SSL_CTX_load_verify_locations(ctx,capemfile,NULL). After attempting SSL_connect from client, the intermediate certificate chain and the EE certificate are received in client side using SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) respectively. After this we call SSL_get_verify_result(ssl) which fails. So question here is that whether we need to add the received chain explicitly to the verify locations in client side? Meaning, do we need to build the chain from client side explicitly by ourselves? First, I made a mistake; it's been a long time since I coded this. CTX_use_certificate_chain_file loads BOTH the entity cert (which must be first in the file) AND the chain certs, and thus REPLACES CTX_use_certificate_file. I'm guessing you have that data, since if _use_certificate_chain_ doesn't contain the EE cert then handshake can't select this auth type (and we have no other) which produces a rather different (and less helpful!) error. But even with that done/fixed in my test environment I DO get verify error 24 invalid CA cert depth 1 (my only intermediate). Is that what you're getting? If so, it looks like maybe the 'purpose' checks have been made stricter since the last time I did this in test, where I have V1/noextension certs. I can't set up a test with real(er) (CA)certs immediately. If you have V1 or otherwise 'substandard' CA certs, you might try enhancing those. These specific checks appear to be bypassed for certs in the truststore, so putting all of the chain above the server EE in the client truststore is an alternative (and works for me). In that case the server only needs to send its EE cert (i.e. only _use_certificate). This is typically more work to set up and manage 'in the wild', but it is an alternative.
RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
From: owner-openssl-us...@openssl.org On Behalf Of Ashok C Sent: Wednesday, 30 November, 2011 00:51 Some more followup questions here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations( ) sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? No, certs to *send* are separate from verifying *received*. Yes, SSL_CTX_user_certificate_chain_file or SSL_CTX_add_extra_chain_cert . So, in this case certificates to be sent need to sent only using the use_certificate* APIs., among which none of them take CAPath as an input. That's not what I said. _use_certificate[_ASN1|file] (but NOT _use_certificate_chain_file) is used to provide an entity's own certificate. It is always sent if authentication is used for this entity in the handshake (for server usually, for client sometimes). _use_certificate_chain_file (not 'user', my typo, sorry) or _add_extra_chain_cert may be used to specify chain or intermediate certs. They are added to the Cert message if authentication is used for this entity. In this case, how does the s_server/s_client implementation work with -CAPath options? Internally does it use just load_verify_locations(*,CAPath) ? Or does it translate the hashes present in CAPath to X509 objects and then use the use_certificate* APIs? s_server and s_client call _load_verify_locations, which uses CAfile and/or CApath to verify subsequently received cert(s). It does NOT use them as own (entity) or chain certs. To be more clear, is there any option in which we can use CAPath to send certificates? No. CApath within OpenSSL is only used for verifying received cert(s). s_server and s_client do not have any feature to send chain certs. They are only test/sample programs; if you want something different, use your own program (perhaps based on them, if you wish). 1. I doubt there's a bug in OpenSSL here; this is very widely used functionality; both CAfile and CApath have worked for me in all versions I've used. What version(s) are you running, is it vanilla build or any mods/patches, and built how? We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64 environment with few CVE patches. I still have 0.9.8g builds (and other 0.9.8) around for support. On Solaris/sparc, Linux/x86, and Windows/x86 both CAfile and CApath work equivalently and as expected. 1.0.0c also works on all, and 1.0.0e on the first two (haven't done 1.0.0e on Windows because no longer needed on the systems I support). I don't do specific x86_64 builds, we just run x86 code on those machines, but I can't imagine this would be an ISA-dependent bug. (As opposed to some crypto primitives like AES and SHA1, which do have different assembly code -- but are also very well tested.) As I asked before, can you reproduce with s_server and s_client? If so, post exact files (using a throwaway key) and we can try to look at it (although the X509-store/lookup stuff is in my opinion among the most confusing part of OpenSSL code). If it only occurs in your program(s), I suspect your program(s). One idea springs to mind: as I said CAfile is read into memory and kept there while CApath is read from disk when needed, so maybe something in your program is clobbering memory. That's a very common mistake in C (and C++). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, Keeping the things you have mentioned in mind, this is how it goes. In server side, EE key is loaded using SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, eepemfile,SSL_FILETYPE_PEM); And the intermediate certificate chain is loaded using SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain contains intermediate CA certs without the rootCA. In client side, rootCA is loaded using SSL_CTX_load_verify_locations(ctx,capemfile,NULL). After attempting SSL_connect from client, the intermediate certificate chain and the EE certificate are received in client side using SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) respectively. After this we call SSL_get_verify_result(ssl) which fails. So question here is that whether we need to add the received chain explicitly to the verify locations in client side? Meaning, do we need to build the chain from client side explicitly by ourselves? Regds, Ashok On Fri, Dec 2, 2011 at 5:33 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Ashok C Sent: Wednesday, 30 November, 2011 00:51 Some more followup questions here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations( ) sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? No, certs to *send* are separate from verifying *received*. Yes, SSL_CTX_user_certificate_chain_file or SSL_CTX_add_extra_chain_cert . So, in this case certificates to be sent need to sent only using the use_certificate* APIs., among which none of them take CAPath as an input. That's not what I said. _use_certificate[_ASN1|file] (but NOT _use_certificate_chain_file) is used to provide an entity's own certificate. It is always sent if authentication is used for this entity in the handshake (for server usually, for client sometimes). _use_certificate_chain_file (not 'user', my typo, sorry) or _add_extra_chain_cert may be used to specify chain or intermediate certs. They are added to the Cert message if authentication is used for this entity. In this case, how does the s_server/s_client implementation work with -CAPath options? Internally does it use just load_verify_locations(*,CAPath) ? Or does it translate the hashes present in CAPath to X509 objects and then use the use_certificate* APIs? s_server and s_client call _load_verify_locations, which uses CAfile and/or CApath to verify subsequently received cert(s). It does NOT use them as own (entity) or chain certs. To be more clear, is there any option in which we can use CAPath to send certificates? No. CApath within OpenSSL is only used for verifying received cert(s). s_server and s_client do not have any feature to send chain certs. They are only test/sample programs; if you want something different, use your own program (perhaps based on them, if you wish). 1. I doubt there's a bug in OpenSSL here; this is very widely used functionality; both CAfile and CApath have worked for me in all versions I've used. What version(s) are you running, is it vanilla build or any mods/patches, and built how? We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64 environment with few CVE patches. I still have 0.9.8g builds (and other 0.9.8) around for support. On Solaris/sparc, Linux/x86, and Windows/x86 both CAfile and CApath work equivalently and as expected. 1.0.0c also works on all, and 1.0.0e on the first two (haven't done 1.0.0e on Windows because no longer needed on the systems I support). I don't do specific x86_64 builds, we just run x86 code on those machines, but I can't imagine this would be an ISA-dependent bug. (As opposed to some crypto primitives like AES and SHA1, which do have different assembly code -- but are also very well tested.) As I asked before, can you reproduce with s_server and s_client? If so, post exact files (using a throwaway key) and we can try to look at it (although the X509-store/lookup stuff is in my opinion among the most confusing part of OpenSSL code). If it only occurs in your program(s), I suspect your program(s). One idea springs to mind: as I said CAfile is read into memory and kept there while CApath is read from disk when needed, so maybe something in your program is clobbering memory. That's a very common mistake in C (and C++). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, Thanks for the reply. Some more followup questions here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations( ) sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? No, certs to *send* are separate from verifying *received*. Yes, SSL_CTX_user_certificate_ chain_file or SSL_CTX_add_extra_chain_cert . So, in this case certificates to be sent need to sent only using the use_certificate* APIs., among which none of them take CAPath as an input. In this case, how does the s_server/s_client implementation work with -CAPath options? Internally does it use just load_verify_locations(*,CAPath) ? Or does it translate the hashes present in CAPath to X509 objects and then use the use_certificate* APIs? To be more clear, is there any option in which we can use CAPath to send certificates? 1. I doubt there's a bug in OpenSSL here; this is very widely used functionality; both CAfile and CApath have worked for me in all versions I've used. What version(s) are you running, is it vanilla build or any mods/patches, and built how? We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64 environment with few CVE patches. On Tue, Nov 29, 2011 at 9:51 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Ashok C Sent: Monday, 28 November, 2011 00:35 One more question here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations() sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? No, certs to *send* are separate from verifying *received*. Yes, SSL_CTX_user_certificate_chain_file or SSL_CTX_add_extra_chain_cert . Similar but less obvious, if you use client auth (i.e. client presents cert) the CA name(s) requested in the CertRequest are separate from the CA cert(s) actually used for verification. Often you want to make these the same, but it's not automatic. Use SSL_[CTX_]set_client_CA_list or SSL_[CTX_]add_client_CA . P.S. My previous query also is unanswered. It would be great if I get some responses to that also ;) From: Ashok C ash@gmail.com Date: Wed, Nov 23, 2011 at 12:55 PM We are implementing multi-layer support for our openssl-based PKI solution and had the following query: The usual term for what I think you mean is multi-LEVEL CAs, or hierarchical CAs. Currently our PKI solution supports only single layer CA support and we use SSL_CTX_load_verify_locations API with the CAFile option, meaning that the service loads the CA certificate from a PEM file. When testing multi-layer support between a client-server model with SSL_VERIFY_PEER set to true, we observed that using the CAFile (with all CA certificates- root + intermediate concatenated into a single PEM file) does not work anymore. But using CAPath option (storing each CA in separate file, creating hashes for them in a directory and providing that directory in CAPath) seems to work fine. Is this a known bug with openSSL or is it something that we are doing wrong. 1. I doubt there's a bug in OpenSSL here; this is very widely used functionality; both CAfile and CApath have worked for me in all versions I've used. What version(s) are you running, is it vanilla build or any mods/patches, and built how? 2. What exactly are you testing, and what exactly is the error(s)? Can you reproduce it with commandline s_client and/or s_server? 3. For SSL/TLS it is common, but not universal, for the server to provide in its handshake all intermediate CA certs, and similarly for the client to do so if client-auth is used. If all peers of a relier do this it doesn't need to configure any intermediate certs, only the root(s). This is often more convenient, since for (some? many?) public CAs the intermediates tend to change more often, and the entity that gets a cert from the CA may be the first to know. You don't say if your 'solution' uses public CAs or your own CA(s); if the latter presumably the behavior is more under your control. If you are using OpenSSL cert verification (and perhaps other functions) for some other protocol/application/whatever, answer may be different. 4. It's not clear to me if it's standard, but OpenSSL always verifies up to a root in the truststore, even if a lower intermediate cert is also in the truststore. This is the same for CAfile and/or CApath. Also, from the openSSL community perspective, is it advisable to use CAFile option or CAPath option when providing multi-layer support? Maybe. See above about which CA certs to configure. If you mean a choice between CAfile and CApath, it's
RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
From: owner-openssl-us...@openssl.org On Behalf Of Ashok C Sent: Monday, 28 November, 2011 00:35 One more question here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations() sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? No, certs to *send* are separate from verifying *received*. Yes, SSL_CTX_user_certificate_chain_file or SSL_CTX_add_extra_chain_cert . Similar but less obvious, if you use client auth (i.e. client presents cert) the CA name(s) requested in the CertRequest are separate from the CA cert(s) actually used for verification. Often you want to make these the same, but it's not automatic. Use SSL_[CTX_]set_client_CA_list or SSL_[CTX_]add_client_CA . P.S. My previous query also is unanswered. It would be great if I get some responses to that also ;) From: Ashok C ash@gmail.com Date: Wed, Nov 23, 2011 at 12:55 PM We are implementing multi-layer support for our openssl-based PKI solution and had the following query: The usual term for what I think you mean is multi-LEVEL CAs, or hierarchical CAs. Currently our PKI solution supports only single layer CA support and we use SSL_CTX_load_verify_locations API with the CAFile option, meaning that the service loads the CA certificate from a PEM file. When testing multi-layer support between a client-server model with SSL_VERIFY_PEER set to true, we observed that using the CAFile (with all CA certificates- root + intermediate concatenated into a single PEM file) does not work anymore. But using CAPath option (storing each CA in separate file, creating hashes for them in a directory and providing that directory in CAPath) seems to work fine. Is this a known bug with openSSL or is it something that we are doing wrong. 1. I doubt there's a bug in OpenSSL here; this is very widely used functionality; both CAfile and CApath have worked for me in all versions I've used. What version(s) are you running, is it vanilla build or any mods/patches, and built how? 2. What exactly are you testing, and what exactly is the error(s)? Can you reproduce it with commandline s_client and/or s_server? 3. For SSL/TLS it is common, but not universal, for the server to provide in its handshake all intermediate CA certs, and similarly for the client to do so if client-auth is used. If all peers of a relier do this it doesn't need to configure any intermediate certs, only the root(s). This is often more convenient, since for (some? many?) public CAs the intermediates tend to change more often, and the entity that gets a cert from the CA may be the first to know. You don't say if your 'solution' uses public CAs or your own CA(s); if the latter presumably the behavior is more under your control. If you are using OpenSSL cert verification (and perhaps other functions) for some other protocol/application/whatever, answer may be different. 4. It's not clear to me if it's standard, but OpenSSL always verifies up to a root in the truststore, even if a lower intermediate cert is also in the truststore. This is the same for CAfile and/or CApath. Also, from the openSSL community perspective, is it advisable to use CAFile option or CAPath option when providing multi-layer support? Maybe. See above about which CA certs to configure. If you mean a choice between CAfile and CApath, it's up to you. As far as the code goes the only differences are: - CAfile is read once, when you call _load_verify, and kept in memory. It is not updated, unless your program calls again. The memory it uses is rarely an issue on desktop class devices unless you have millions of CA certs, but might be on smaller e.g. mobile devices, but you probably don't use OpenSSL there. Any format error in the file is detected at load time. - CApath is read when needed, during handshake. If your program runs more than a short time and makes or accepts new connections you can get dynamic updates. If your program handles a very high rate of handshakes this could be a performance issue. Any format error may not be detected until a handshake uses that cert. One caveat: the hash used for CApath names changed between 0.9.8 and 1.0.0. If you need to support systems or users on both 'families', that may be a bother. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi, One more question here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations() sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? P.S. My previous query also is unanswered. It would be great if I get some responses to that also ;) Regds, Ashok -- Forwarded message -- From: Ashok C ash@gmail.com Date: Wed, Nov 23, 2011 at 12:55 PM Subject: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg. To: openssl-users@openssl.org Hi, We are implementing multi-layer support for our openssl-based PKI solution and had the following query: Currently our PKI solution supports only single layer CA support and we use SSL_CTX_load_verify_locations API with the CAFile option, meaning that the service loads the CA certificate from a PEM file. When testing multi-layer support between a client-server model with *SSL_VERIFY_PEER *set to true, we observed that using the CAFile(with all CA certificates- root + intermediate concatenated into a single PEM file) does not work anymore. But using CAPath option (storing each CA in separate file, creating hashes for them in a directory and providing that directory in CAPath) seems to work fine. Is this a known bug with openSSL or is it something that we are doing wrong.* * Also, from the openSSL community perspective, is it advisable to use CAFile option or CAPath option when providing multi-layer support? Regds, Ashok
