Certificate chain issue
Hi all, I have just created a new CA which has the extension to allow client authentication. My previous CA worked fine without this extension but some client application now requires that I set it. So I've created a new client key pair and signed it with the new CA, but when I use openssl verify to test them, they do not verify. I get the following error: $ openssl verify -CAfile CA/cacert.pem client.cert stdin: CN = d8ab98a0252208818a29d5548bd833d40e85e4fa14bf146dc04be5139418fae2, emailAddress = a...@gmail.commailto:ljbr...@gmail.com, C = aa error 20 at 0 depth lookup:unable to get local issuer certificate If I look at the new client certificate's chain I get: ~$ openssl x509 -issuer -subject -noout -in client.cert issuer= /C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost subject= /CN=d8ab98a0252208818a29d5548bd833d40e85e4fa14bf146dc04be5139418fae2/emailAddress=a...@gmail.commailto:ljbr...@gmail.com/C=aa and the CA certificate is selfsigned: ~$ openssl x509 -issuer -subject -noout -in CA/cacert.pem issuer= /C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost subject= /C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost The extensions for the CA are now: X509v3 extensions: X509v3 Subject Key Identifier: ED:51:C6:3B:A3:72:B3:F5:33:80:F0:7C:15:FD:CE:FF:6C:B6:07:6A X509v3 Authority Key Identifier: keyid:ED:51:C6:3B:A3:72:B3:F5:33:80:F0:7C:15:FD:CE:FF:6C:B6:07:6A DirName:/C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost serial:A4:48:38:09:CB:16:6A:D0 X509v3 Basic Constraints: CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign I just cannot understand this verification problem - the client is directly signed by the root CA!? Any help appreciated Thanks LJB
Re: [openssl-users] Certificate chain issue
Try these: - split the certificates from your CA/cecert.pem into individual files with correct hashes - run strace -eopen openssl verify -CApath yourcacertsdirectory client.cert -- Erwann ABALEA Le 04/06/2013 09:02, Leon Brits a écrit : Hi all, I have just created a new CA which has the extension to allow client authentication. My previous CA worked fine without this extension but some client application now requires that I set it. So I've created a new client key pair and signed it with the new CA, but when I use openssl verify to test them, they do not verify. I get the following error: $ openssl verify -CAfile CA/cacert.pem client.cert stdin: CN = d8ab98a0252208818a29d5548bd833d40e85e4fa14bf146dc04be5139418fae2, emailAddress = a...@gmail.com mailto:ljbr...@gmail.com, C = aa error 20 at 0 depth lookup:unable to get local issuer certificate If I look at the new client certificate's chain I get: ~$ openssl x509 -issuer -subject -noout -in client.cert issuer= /C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost subject= /CN=d8ab98a0252208818a29d5548bd833d40e85e4fa14bf146dc04be5139418fae2/emailAddress=a...@gmail.com mailto:ljbr...@gmail.com/C=aa and the CA certificate is selfsigned: ~$ openssl x509 -issuer -subject -noout -in CA/cacert.pem issuer= /C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost subject= /C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost The extensions for the CA are now: X509v3 extensions: X509v3 Subject Key Identifier: ED:51:C6:3B:A3:72:B3:F5:33:80:F0:7C:15:FD:CE:FF:6C:B6:07:6A X509v3 Authority Key Identifier: keyid:ED:51:C6:3B:A3:72:B3:F5:33:80:F0:7C:15:FD:CE:FF:6C:B6:07:6A DirName:/C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost serial:A4:48:38:09:CB:16:6A:D0 X509v3 Basic Constraints: CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign I just cannot understand this verification problem - the client is directly signed by the root CA!? Any help appreciated Thanks LJB
PKCS#1 key vs PKCS#8...
Hello, I am using strongswan(v_4.5.3) for ipsec, that uses my X509 certificate and RSA private key. If i use RSA private key(un-encrypted) that is PKCS#8 encoded, then strongswan is not able to load the key. But it works, if i use a traditional PKCS#1 encoded RSA key. Could anyone explain, which one is a better recommendation (PKCS#1 or PKCS#8) ? Regards, Sanjaya
Re: Callback access to X509_STORE_CTX-untrusted?
On Mon, Jun 03, 2013 at 11:32:31PM +, Viktor Dukhovni wrote: I want to use SSL_CTX_set_cert_verify_callback() to customize how certificate verification is performed. I need to be able to selectively add/remove from the set of untrusted additional certificates in X509_STORE_CTX. Unfortunately, while: X509_STORE_CTX_set_chain() sets ctx-untrusted, the similarly named: X509_STORE_CTX_get_chain() returns ctx-chain, which is already populated and useful during the simpler one cert at a time verification callback, but is always empty at the start of the cert_verify_callback(). I could simply bypass the API and directly manipulate ctx-untrusted, but I am reluctant to do that. Should I go ahead and do that? Note, to implement DANE, I using 1.0.0 or later only. So if with 1.x.y there is a reasonable expectation that libcrypto versions with the same SONAME don't vary in the offset of the untrusted member in X509_STORE_CTX, that would be good to know. Will there perhaps be a library feature that exposes the chain elements to the cert_verify_callback? Any feedback? Is it safe to access (read-only by cloning the chain) ctx-untrusted? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback access to X509_STORE_CTX-untrusted?
On Tue, Jun 04, 2013, Viktor Dukhovni wrote: On Mon, Jun 03, 2013 at 11:32:31PM +, Viktor Dukhovni wrote: I want to use SSL_CTX_set_cert_verify_callback() to customize how certificate verification is performed. I need to be able to selectively add/remove from the set of untrusted additional certificates in X509_STORE_CTX. Unfortunately, while: X509_STORE_CTX_set_chain() sets ctx-untrusted, the similarly named: X509_STORE_CTX_get_chain() returns ctx-chain, which is already populated and useful during the simpler one cert at a time verification callback, but is always empty at the start of the cert_verify_callback(). I could simply bypass the API and directly manipulate ctx-untrusted, but I am reluctant to do that. Should I go ahead and do that? Note, to implement DANE, I using 1.0.0 or later only. So if with 1.x.y there is a reasonable expectation that libcrypto versions with the same SONAME don't vary in the offset of the untrusted member in X509_STORE_CTX, that would be good to know. Well since 1.0.x have to be binary compatible the structure offset wont change. Due to the way X509_STORE_CTX is accessed it's can't really be modified at all for 1.0.x. Will there perhaps be a library feature that exposes the chain elements to the cert_verify_callback? Any feedback? Is it safe to access (read-only by cloning the chain) ctx-untrusted? Yes it is. Due to the way ctx-untrusted is used it isn't safe to modify the contents of ctx-untrusted: it uses the supplied application chain pointer directly and modifying that could have unpredictable results. 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: Callback access to X509_STORE_CTX-untrusted?
On Tue, Jun 04, 2013 at 04:38:42PM +0200, Dr. Stephen Henson wrote:
Note, to implement DANE, I using 1.0.0 or later only. So if with
1.x.y there is a reasonable expectation that libcrypto versions
with the same SONAME don't vary in the offset of the untrusted
member in X509_STORE_CTX, that would be good to know.
Well since 1.0.x have to be binary compatible the structure offset wont
change.
Due to the way X509_STORE_CTX is accessed it's can't really be modified at all
for 1.0.x.
And the SONAME changes for 1.1.x, if the ABI is changed, right?
Will there perhaps be a library feature that exposes the chain
elements to the cert_verify_callback?
Any feedback? Is it safe to access (read-only by cloning the chain)
ctx-untrusted?
Yes it is. Due to the way ctx-untrusted is used it isn't safe to modify the
contents of ctx-untrusted: it uses the supplied application chain pointer
directly and modifying that could have unpredictable results.
I don't intend to change the chain referenced by untrusted, I
only need read-only access to the original chain to create a new
untrusted chain with a subset of the original elements + some
additional elements. I can then use X509_STORE_CTX_set_chain()
to set ctx-untrusted to point to my new chain.
It sounds like this is not going to be a problem. The basic plan for the
cert_verify_callback is:
int cert_verify_callback(X509_STORE_CTX *ctx, void *appctx)
{
STACK_OF(X509) *myuntrusted = copy_and_prune_untrusted(appctx,
ctx-untrusted);
STACK_OF(X509) *mytrusted = trust_anchor_stack(appctx);
X509_STORE_CTX_set_chain(myuntrusted);
X509_STORE_CTX_trusted_stack(ctx, mytrusted);
return X509_verify_cert(ctx);
}
This validates the chain via a custom set of trusted roots and a
modified copy of the list untrusted certificates. The only thing
missing from the OpenSSL library to support this better is an
accessor function for ctx-untrusted.
diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index afb6016..ed595d2 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -2103,6 +2103,11 @@ X509 *X509_STORE_CTX_get_current_cert(X509_STORE_CTX
*ctx)
return ctx-current_cert;
}
+STACK_OF(X509) *X509_STORE_CTX_get_untrusted(X509_STORE_CTX *ctx)
+ {
+ return ctx-untrusted;
+ }
+
STACK_OF(X509) *X509_STORE_CTX_get_chain(X509_STORE_CTX *ctx)
{
return ctx-chain;
The other thing that I noticed while performing RTFS, is that after
certificate verification completes, the chain reported by
SSL_get_peer_cert_chain() is the raw untrusted chain off the
wire, not the verified chain built by X509_verify_cert(). Is that
intentional?
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
SSL/TLS protocol versions and their supported cipher suites
I'm a little confused about which cipher suites are supported by which SSL/TLS protocol versions. I'm using Appendix C of the TLS 1.0, 1.1, and 1.2 RFCs, respectively, as a starting point for which cipher suites are supported in which version of the protocol, but I'm not sure how to parse the fact that some cipher suites are missing between documents. For example, the export cipher suites do not appear in Appendix C of the TLS 1.1 RFC. Does that mean that they are not available for use in TLS 1.1? Or does each revision of TLS implicitly support the list of cipher suites from the prior versions and then simply add new ones? On a related note, I assume the cipher suites defined in their own RFCs (AES in RFC3268, Cameillia in RFC4132, etc.) for TLS 1.0 are also supported in TLS 1.1 and 1.2? It's very possible all of this is spelled out somewhere that I haven't come across yet. What does is mean when openssl cipers -tls -v shows SSLv3? I assume that means that the specific cipher suite is supporte in SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2? The cipher suites that are exclusive to TLS 1.2 are marked by TLSv1.2? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS protocol versions and their supported cipher suites
Ahhh, it looks like Appendix A.5 answers my questions more easily than Appendix C. I believe these are the answers: In fact, TLS 1.1 does prohibit the use of the export cipher suites in TLS 1.0. So there are effectively a few (9 by my count) cipher suites that supported in TLS 1.0 that are prohibited in TLS 1.1. No, each revision of the of TLS does not implicitly support the list of cipher suites from the prior versions. For example, it seems that TLS v1.2 dropped support for single DES cipher suites. Yes, the AES cipher suites defined in RFC3268 are supported in TLS 1.1 and 1.2. I mistakenly thought RFC3268 was specific to TLS 1.0. It is for TLS and not confined to a particular version - although TLS 1.2 explicitly incorporated them into its RFC. For the most part, the SSLv3 designation on the openssl ciphers -v output means that the cipher suite is at least support by SSL 3 and TLS 1.0 (and TLS 1.1 except for the export cipher suites as noted above). The TLSv1.2 designation means that the cipher suite is specific to TLS 1.2. I'm a little confused about which cipher suites are supported by which SSL/TLS protocol versions. I'm using Appendix C of the TLS 1.0, 1.1, and 1.2 RFCs, respectively, as a starting point for which cipher suites are supported in which version of the protocol, but I'm not sure how to parse the fact that some cipher suites are missing between documents. For example, the export cipher suites do not appear in Appendix C of the TLS 1.1 RFC. Does that mean that they are not available for use in TLS 1.1? Or does each revision of TLS implicitly support the list of cipher suites from the prior versions and then simply add new ones? On a related note, I assume the cipher suites defined in their own RFCs (AES in RFC3268, Cameillia in RFC4132, etc.) for TLS 1.0 are also supported in TLS 1.1 and 1.2? It's very possible all of this is spelled out somewhere that I haven't come across yet. What does is mean when openssl cipers -tls -v shows SSLv3? I assume that means that the specific cipher suite is supporte in SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2? The cipher suites that are exclusive to TLS 1.2 are marked by TLSv1.2? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Convertion of pkcs8 to pkcs1 key...
Hello, Could anyone let me know which is the suitable openssl command to convert PKCS#8 key to traditional PKCS#1 key in openssl_1.0.0? I used the below command, and it works in openssl_1.0.0:- openssl rsa -in pkcs8.pem -out pkcs1.pem But if i use the below command, it doesn't work in openssl_1.0.0 (whereas it works in openssl_0.9.8):- openssl pkcs8 -nocrypt -in pkcs8.pem -out pkcs1.pem Regards, Sanjaya
Change in behavior of api PEM_write_PrivateKey() between 0.9.8 and 1.0.0
Hello, I have few queries wrt the RSA private key generation and writing using openssl. Could anybody please clearify. (1). Has the behavior of api PEM_write_PrivateKey() has been changed between openssl 0.9.8 and 1.0.0 ? (2). The above api uses PKCS#8 encoding (while writing) by default in 1.0.0, but uses PKCS#1 in 0.9.8. Is this correct ? (3). But while generating RSA key using openssl command, no change in the behavior, in both the versions. Is this correct ? Regards, Sanjaya
