Re: OpenSSL PKI Tutorial updated
On 25.03.2014, at 17:44, Zack Williams wrote: 1. Is there a reason you're not using SHA-256 hash by default - it appears that SHA1 is being recommended against currently: http://www.digicert.com/sha-2-ssl-certificates.htm No reason. Just for maximum compatibility. Every software can do SHA1. But this comes up a lot and I might switch to sha256 the next time around. 2. I couldn't figure out what the [additional_oids] section of the Expert example's root-ca.conf file is for - either through research or going through the commit history. Could you elaborate on what that accomplishes? These define symbolic names for policy OIDs used in the certificatePolicies extension. You could well use the raw numbers without mapping them to names. Also note that policies are entirely optional and you are free to ignore them if you don't have a use case. 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Pathlen is not used on root CA certs. A lot of things are not used on root CA certs. They only serve to publish a key and ID. I don't use pathlen on intermediate CAs either, just signing CAs. Thank you for your feedback, Stefan -- Stefan H. Holek ste...@epy.co.at __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL PKI Tutorial updated
On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek ste...@epy.co.at wrote: On 25.03.2014, at 17:44, Zack Williams wrote: ... 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Pathlen is not used on root CA certs. ... RFC 5280 might disagree. For example, section 6.1.2 (k): (k) max_path_length: this integer is initialized to n, is decremented for each non-self-issued certificate in the path, and may be reduced to the value in the path length constraint field within the basic constraints extension of a CA certificate. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Data race with SSL_SESSION reuse and tlsext_tick
Hi there,
I'm working on an application that shares SSL_SESSION pointers between
SSL_CTXs in multiple threads. The logic for sharing the session is
roughly as follows:
lock(mtx);
sp = get_cached_session_pointer();
if (!SSL_set_session(ctx, sp)) {
SSL_set_session(ctx, NULL);
}
unlock(mtx);
r = SSL_connect(ctx)
if (r 0 !SSL_session_reused(ctx)) {
lock(mtx);
set_cached_session_pointer(SSL_get1_session(ctx));
unlock(mtx);
SSL_SESSION_free(sp);
}
With OpenSSL 1.0.1e, I'm running into what looks like a race condition
in which SSL_connect will call ssl3_get_new_session_ticket when it is
reusing a shared session. In this case, there is a race when multiple
threads simultaneously enter this state and both observe
ctx-session-tlsext_tick to be non-NULL, both will call OPENSSL_free,
and this can crash, especially with custom allocators. This race
triggers quite rarely doing about 7 connections per second (that's
about all the information I can offer as to the environment), but
quite rarely is unfortunately still often enough to need to fix
this.
It seems to me that the only way to do this safely is for any time we
enter the state SSL3_ST_CR_SESSION_TICKET_[AB], we call
ssl_get_new_session prior to the ssl3_get_new_session_ticket call. If
we were to just serialize the ssl3_get_new_session_ticket alloc /
free, it seems that the race still exists -- two new tickets may be
negotiated, but only one will wind up stored in the session. I imagine
this would have consequences in later communications. Alternatively,
hanging the tlsext_tick, tlsext_ticklen, and tlsext_tick_lifetime_hint
off of the SSL_CTX instead of SSL_SESSION would also work.
Serializing SSL_connect also fixes it (of course) but adding
indeterminate latency to future connects to solve the problem doesn't
work for me.
I'd greatly appreciate feedback as to whether this analysis makes
sense (and if so which approach to fixing it might be preferable for
submitting a patch) given that I'm more of a concurrency and
performance guy than a crypto guy. I'm also always open to being told
that I'm doing it wrong; in this case, I would appreciate insight into
how I might better implement the session reuse code to avoid this
race.
--dho
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: OpenSSL PKI Tutorial updated
Le 27/03/2014 11:14, Jeffrey Walton a écrit : On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek ste...@epy.co.at wrote: On 25.03.2014, at 17:44, Zack Williams wrote: ... 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Pathlen is not used on root CA certs. ... RFC 5280 might disagree. For example, section 6.1.2 (k): (k) max_path_length: this integer is initialized to n, is decremented for each non-self-issued certificate in the path, and may be reduced to the value in the path length constraint field within the basic constraints extension of a CA certificate. No disagreement here. Initial value of the max_path_len is set to the length of certificate chain, and it's not taken from the BasicConstraints extension of the trust anchor. The rest of the phrase (after the first comma) explains how it will decrease, but it's detailed later in the algo. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL PKI Tutorial updated
Hello, On Thu, March 27, 2014 10:47, Stefan H. Holek wrote: 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Pathlen is not used on root CA certs. A lot of things are not used on root CA certs. They only serve to publish a key and ID. I don't use pathlen on intermediate CAs either, just signing CAs. Does this mean, you use certificates with a complete chain of at least 4 certificates? - root ca cert. no pathlen - intermediate ca cert. also no pathlen - signing ca cert. with pathlen - end cert what is here said about the key length? my CA uses a root with 4096 bits RSA key; does it make a sense, that an intermediate or the signing ca has a stronger key than the root CA? Greetings, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE-ECDSA Support
hi Jeff, Thanks for the response, but I'm still having trouble. As for TLSv1.2: With the OS version of openssl, my default connection looks to be TLSv1.1 However, if I add -tls1_2 to the call, I get this: SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Should this be consider accurate (or should I verify with wireshark?)? I compiled the openssl-1.0.2-beta and it's default connections looks to be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA. One interesting point is that mail.google.com has at least two certificates one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both certs with gnutls-cli. I made a test certificate using ECDHE-ECDSA so I'm guessing that means the capability is compiled in. Cheers, -Tom On Wed, Mar 26, 2014 at 6:43 PM, Jeffrey Walton noloa...@gmail.com wrote: I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any case. ... Any ideas why I can't do that with openssl? Ubuntu disables TLS 1.1 and 1.2 in their version of OpenSSL. See, for example, OpenSSL downlevel version is 1.0.0, and does not support TLS 1.2, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576. You should be able to connect with -tls1; or build/install OpenSSL yourself and use the one installed at /usr/local/ssl/bin/openssl. openssl s_client -connect mail.google.com:443 -tls1_2 -cipher You can also use -CAfile option for s_client to avoid the verify error. Use Google's Google Internet Authority G2 at http://pki.google.com/. Jeff On Wed, Mar 26, 2014 at 4:14 PM, Thomas Montroy tom.mont...@gmail.com wrote: hi All, I've been trying to make ECDHE-ECDSA connections with openssl and have been having trouble. openssl s_client -connect mail.google.com:443 -tls1_2 This connects with cipher = ECDHE-RSA-AES128-GCM-SHA256 According to Google-Chrome, the cipher for my web-based gmail connection should be: ECDHE-ECDSA-AES128-GCM-SHA256 If I try to make that connection openssl s_client -connect mail.google.com:443 -tls1_2 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 I get: CONNECTED(0003) 139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1440:SSL alert number 40 139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:617: which looks like no connection. I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any case. I downloaded and compiled the latest version of gnutls: This gives an ECDHE-ECDSA connection gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com This gives an ECDHE-RSA gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-RSA mail.google.com So I'm able to see both types of certificates for mail.google.com with gnutls. Any ideas why I can't do that with openssl? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE-ECDSA Support
On Thu, Mar 27, 2014, Thomas Montroy wrote: hi Jeff, Thanks for the response, but I'm still having trouble. As for TLSv1.2: With the OS version of openssl, my default connection looks to be TLSv1.1 However, if I add -tls1_2 to the call, I get this: SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Should this be consider accurate (or should I verify with wireshark?)? I compiled the openssl-1.0.2-beta and it's default connections looks to be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA. One interesting point is that mail.google.com has at least two certificates one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both certs with gnutls-cli. I made a test certificate using ECDHE-ECDSA so I'm guessing that means the capability is compiled in. An interesting little puzzle. I reproduced your results and using Firefox I can see the ECDSA certificate but OpenSSL chokes if you try to restrict the handshake to just ECDSA. After some head scratching I wondered if servername has anything to do with it. OpenSSL doesn't send servername by default but some other applications do. Adding servername like this: openssl s_client -connect mail.google.com:443 -servername mail.google.com does the trick and you then get: Protocol : TLSv1.2 Cipher: ECDHE-ECDSA-AES128-GCM-SHA256 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE-ECDSA Support
Nice catch. Thanks for looking into it. Cheers, -Tom On Thu, Mar 27, 2014 at 9:22 AM, Dr. Stephen Henson st...@openssl.orgwrote: On Thu, Mar 27, 2014, Thomas Montroy wrote: hi Jeff, Thanks for the response, but I'm still having trouble. As for TLSv1.2: With the OS version of openssl, my default connection looks to be TLSv1.1 However, if I add -tls1_2 to the call, I get this: SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Should this be consider accurate (or should I verify with wireshark?)? I compiled the openssl-1.0.2-beta and it's default connections looks to be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA. One interesting point is that mail.google.com has at least two certificates one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both certs with gnutls-cli. I made a test certificate using ECDHE-ECDSA so I'm guessing that means the capability is compiled in. An interesting little puzzle. I reproduced your results and using Firefox I can see the ECDSA certificate but OpenSSL chokes if you try to restrict the handshake to just ECDSA. After some head scratching I wondered if servername has anything to do with it. OpenSSL doesn't send servername by default but some other applications do. Adding servername like this: openssl s_client -connect mail.google.com:443 -servername mail.google.com does the trick and you then get: Protocol : TLSv1.2 Cipher: ECDHE-ECDSA-AES128-GCM-SHA256 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE-ECDSA Support
On Thu, Mar 27, 2014, Dr. Stephen Henson wrote: On Thu, Mar 27, 2014, Thomas Montroy wrote: hi Jeff, Thanks for the response, but I'm still having trouble. As for TLSv1.2: With the OS version of openssl, my default connection looks to be TLSv1.1 However, if I add -tls1_2 to the call, I get this: SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Should this be consider accurate (or should I verify with wireshark?)? I compiled the openssl-1.0.2-beta and it's default connections looks to be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA. One interesting point is that mail.google.com has at least two certificates one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both certs with gnutls-cli. I made a test certificate using ECDHE-ECDSA so I'm guessing that means the capability is compiled in. An interesting little puzzle. I reproduced your results and using Firefox I can see the ECDSA certificate but OpenSSL chokes if you try to restrict the handshake to just ECDSA. After some head scratching I wondered if servername has anything to do with it. OpenSSL doesn't send servername by default but some other applications do. Adding servername like this: openssl s_client -connect mail.google.com:443 -servername mail.google.com does the trick and you then get: Protocol : TLSv1.2 Cipher: ECDHE-ECDSA-AES128-GCM-SHA256 Just had an update from Rob Stradling whose message hasn't made it to the list yet. If OpenSSL is compiled with zlib support you also have to disable compression using -no_comp. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Data race with SSL_SESSION reuse and tlsext_tick
On Wed, Mar 26, 2014 at 05:25:49PM -0400, Devon H. O'Dell wrote: Hi there, I'm working on an application that shares SSL_SESSION pointers between SSL_CTXs in multiple threads. The logic for sharing the session is roughly as follows: lock(mtx); sp = get_cached_session_pointer(); Don't share session *objects*, serialize the session to DER form, and cache that. Each SSL connectiont that wants to re-use a session will de-serialize the session creating a new session object. You'll need the new_session_cb callbacks, ... to detect when new sessions are created despite your best attempt to reuse, and then cache a replacement session. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE-ECDSA Support
Hi Thomas. I was told a while ago that Google's servers will only negotiate ECDHE-ECDSA if the client i) sends the SNI extension and ii) does _not_ offer any compression methods. IINM, s_client always offers zlib compression if zlib support is compiled in. It'd be nice if there was a command line switch for s_client to disable compression (by setting the SSL_OP_NO_COMPRESSION option in the SSL context), but, currently, there isn't. Try: openssl s_client -connect sslanalyzer.comodoca.com:443 I expect you'll find that this connects using ECDHE-ECDSA-AES256-GCM-SHA384. On 27/03/14 12:40, Thomas Montroy wrote: hi Jeff, Thanks for the response, but I'm still having trouble. As for TLSv1.2: With the OS version of openssl, my default connection looks to be TLSv1.1 However, if I add -tls1_2 to the call, I get this: SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Should this be consider accurate (or should I verify with wireshark?)? I compiled the openssl-1.0.2-beta and it's default connections looks to be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA. One interesting point is that mail.google.com http://mail.google.com has at least two certificates one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to mail.google.com http://mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both certs with gnutls-cli. I made a test certificate using ECDHE-ECDSA so I'm guessing that means the capability is compiled in. Cheers, -Tom On Wed, Mar 26, 2014 at 6:43 PM, Jeffrey Walton noloa...@gmail.com mailto:noloa...@gmail.com wrote: I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any case. ... Any ideas why I can't do that with openssl? Ubuntu disables TLS 1.1 and 1.2 in their version of OpenSSL. See, for example, OpenSSL downlevel version is 1.0.0, and does not support TLS 1.2, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576. You should be able to connect with -tls1; or build/install OpenSSL yourself and use the one installed at /usr/local/ssl/bin/openssl. openssl s_client -connect mail.google.com:443 http://mail.google.com:443 -tls1_2 -cipher You can also use -CAfile option for s_client to avoid the verify error. Use Google's Google Internet Authority G2 at http://pki.google.com/. Jeff On Wed, Mar 26, 2014 at 4:14 PM, Thomas Montroy tom.mont...@gmail.com mailto:tom.mont...@gmail.com wrote: hi All, I've been trying to make ECDHE-ECDSA connections with openssl and have been having trouble. openssl s_client -connect mail.google.com:443 http://mail.google.com:443 -tls1_2 This connects with cipher = ECDHE-RSA-AES128-GCM-SHA256 According to Google-Chrome, the cipher for my web-based gmail connection should be: ECDHE-ECDSA-AES128-GCM-SHA256 If I try to make that connection openssl s_client -connect mail.google.com:443 http://mail.google.com:443 -tls1_2 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 I get: CONNECTED(0003) 139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1440:SSL alert number 40 139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:617: which looks like no connection. I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any case. I downloaded and compiled the latest version of gnutls: This gives an ECDHE-ECDSA connection gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com http://mail.google.com This gives an ECDHE-RSA gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-RSA mail.google.com http://mail.google.com So I'm able to see both types of certificates for mail.google.com http://mail.google.com with gnutls. Any ideas why I can't do that with openssl? __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are
How to swap engines / register functionality on the fly
I would like to use default implementations for some ECC operations but the OpenSC pkcs11 engine for other ECDSA operations. At a high level I have a Sign() a Verify() in one app on a server - the Sign() needs to be done via a HSM using PKCS11 interface, using EVP functions. Keys for these operations differ. For system design reasons I want to do Verify() using default implementations, no HSM involved. This Verify currently uses EC_KEY_new() and ECDSA_do_verify(). Even if I /wanted/ HSM to do this I was getting some fips errors despite turning off fips. My thinking was to register the pkcs11 ECDSA functionality JUST before the Sign(): if ( 1 != ( rc = ENGINE_register_ECDSA(HSM_ENGINE_pkcs11( then just after ENGINE_unregister_ECDSA(HSM_ENGINE_pkcs11()); This is getting to the fringe of my understanding; any guidance is much appreciated. -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-swap-engines-register-functionality-on-the-fly-tp48982.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to swap engines / register functionality on the fly
On Thu, Mar 27, 2014, axisofevil wrote: I would like to use default implementations for some ECC operations but the OpenSC pkcs11 engine for other ECDSA operations. At a high level I have a Sign() a Verify() in one app on a server - the Sign() needs to be done via a HSM using PKCS11 interface, using EVP functions. Keys for these operations differ. For system design reasons I want to do Verify() using default implementations, no HSM involved. This Verify currently uses EC_KEY_new() and ECDSA_do_verify(). Even if I /wanted/ HSM to do this I was getting some fips errors despite turning off fips. My thinking was to register the pkcs11 ECDSA functionality JUST before the Sign(): if ( 1 != ( rc = ENGINE_register_ECDSA(HSM_ENGINE_pkcs11( then just after ENGINE_unregister_ECDSA(HSM_ENGINE_pkcs11()); This is getting to the fringe of my understanding; any guidance is much appreciated. If the ENGINE only needs to support HSM private keys then you shouldn't register any methods at all. Calling ENGINGE_load_private_key should get you the appropriate EVP_PKEY structure internally set to redirect operations as appropriate. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL PKI Tutorial updated
On 27.03.2014, at 13:32, Walter H. wrote: Does this mean, you use certificates with a complete chain of at least 4 certificates? - root ca cert. no pathlen - intermediate ca cert. also no pathlen - signing ca cert. with pathlen - end cert Yes, the expert example does that. what is here said about the key length? my CA uses a root with 4096 bits RSA key; does it make a sense, that an intermediate or the signing ca has a stronger key than the root CA? I don't think so. Stefan -- Stefan H. Holek ste...@epy.co.at __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL PKI Tutorial updated
On Thu, Mar 27, 2014 at 2:47 AM, Stefan H. Holek ste...@epy.co.at wrote: No reason. Just for maximum compatibility. Every software can do SHA1. But this comes up a lot and I might switch to sha256 the next time around. It appears that even what most legacy web browsers and servers support sha256, given these lists: http://www.tbs-certificates.co.uk/FAQ/en/476.html http://www.tbs-certificates.co.uk/FAQ/en/477.html Are there other lists of other products that are modern (or still in active use), but lack sha256 compatibility? 2. I couldn't figure out what the [additional_oids] section of the Expert example's root-ca.conf file is for - either through research or going through the commit history. Could you elaborate on what that accomplishes? These define symbolic names for policy OIDs used in the certificatePolicies extension. You could well use the raw numbers without mapping them to names. Also note that policies are entirely optional and you are free to ignore them if you don't have a use case. I assume that verifying that only correct/allowed OIDs are used in a cert chain happens whether or not they get used by the rest of the software, correct? Or is this configurable? Thank you for your feedback, Thank you for working on this! - Zack __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
