Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, 2009-06-03 at 17:59 -0400, Victor Duchovni wrote: The SSL_CTX_use_certificate_chain_file() API is a very admin friendly way to support installation of cert + chain and even key + cert + chain, as the key can also be stored in the same file (ideally mode 0600 or passphrase-protected). Much like a PKCS#12 file, in fact. I'll make my VPN client use SSL_CTX_use_certificate_chain_file(), and I'll also look at making our cert-fetching scripts generate an appropriate file. Thanks. In the meantime the bug seems to have been fixed on the server so it doesn't _need_ me to submit a full certificate chain any more. Either they've deployed a fix for RT#1942, or the admins have just removed the old, conflicting CA certs from the CA bundle. -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Tue, 2009-06-02 at 21:39 -0400, Victor Duchovni wrote: The CAfile is for verification, not for sending alon the trust chain of a given certificate. OpenSSL currently _does_ use the CAfile for sending along the trust chain of its client certificate. It's buggy, but it tries :) DO NOT append your CAfile to your certificate, instead include just the leaf cert, then the issuing CAs bottom-up in the right order. AFAICT that doesn't make any difference -- OpenSSL doesn't use them from there anyway (unless it's a PKCS#12 file, but the client application has to handle all that manually anyway). -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, Jun 03, 2009 at 07:27:00PM +0100, David Woodhouse wrote:
On Tue, 2009-06-02 at 21:39 -0400, Victor Duchovni wrote:
The CAfile is for verification, not for sending alon the trust chain
of a given certificate.
OpenSSL currently _does_ use the CAfile for sending along the trust
chain of its client certificate. It's buggy, but it tries :)
DO NOT append your CAfile to your certificate, instead include just
the leaf cert, then the issuing CAs bottom-up in the right order.
AFAICT that doesn't make any difference -- OpenSSL doesn't use them from
there anyway (unless it's a PKCS#12 file, but the client application has
to handle all that manually anyway).
For most OpenSSL based applications that use a key+cert own (rather
than just verify remote certs), the private key and own cert are loaded
via code along the lines of (this is from Postfix):
/*
* We need both the private key (in key_file) and the public key
* certificate (in cert_file). Both may specify the same file.
*
* Code adapted from OpenSSL apps/s_cb.c.
*/
ERR_clear_error();
if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) = 0) {
msg_warn(cannot get %s certificate from file %s:
disabling TLS support, cert_type, cert_file);
tls_print_errors();
return (0);
}
if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) = 0) {
msg_warn(cannot get %s private key from file %s:
disabling TLS support, cert_type, key_file);
tls_print_errors();
return (0);
}
/*
* Sanity check.
*/
if (!SSL_CTX_check_private_key(ctx)) {
msg_warn(%s private key in %s does not match public key in %s:
disabling TLS support, cert_type, key_file, cert_file);
return (0);
}
return (1);
with SSL_CTX_use_certificate_chain_file() the entire trust chain is
loaded from the provided file bottom-up order. The first certificate
is the leaf and must match the private key provided.
If you application is using an interface for loading discrete certificates,
it needs to be configured to load the required certificates one at a time,
or via PKCS#12 if that is what it wants to do. The above code-path is
far simpler.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, 2009-06-03 at 15:02 -0400, Victor Duchovni wrote: with SSL_CTX_use_certificate_chain_file() the entire trust chain is loaded from the provided file bottom-up order. The first certificate is the leaf and must match the private key provided. Ah, right. Most files I've encountered have had only the _one_ certificate. The code path you describe seems to be labelled with /* A Thawte special :-) */ throughout the addition and usage of those extra certs -- is that really the way it's _supposed_ to be done? -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Wed, Jun 03, 2009 at 10:24:47PM +0100, David Woodhouse wrote: On Wed, 2009-06-03 at 15:02 -0400, Victor Duchovni wrote: with SSL_CTX_use_certificate_chain_file() the entire trust chain is loaded from the provided file bottom-up order. The first certificate is the leaf and must match the private key provided. Ah, right. Most files I've encountered have had only the _one_ certificate. The code path you describe seems to be labelled with /* A Thawte special :-) */ Perhaps Thawte were the first to mass-market leaf certs signed by intermediate CAs, making the need for additional certs to be included in the trust chain beyond the leaf cert. throughout the addition and usage of those extra certs -- is that really the way it's _supposed_ to be done? The SSL_CTX_use_certificate_chain_file() API is a very admin friendly way to support installation of cert + chain and even key + cert + chain, as the key can also be stored in the same file (ideally mode 0600 or passphrase-protected). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Mon, 2009-06-01 at 17:15 -0400, Victor Duchovni wrote: I found another strange behaviour that I didn't expect -- the _order_ of the certificates in the cafile seems to be important. Yes, the TLS protocol requires the trust chain to be delivered bottom-up. That makes sense, but we're talking about the order of the certificates in the cafile, not on the wire. OpenSSL really ought to get that right. The problem turned out to be that OpenSSL was picking the _wrong_ certificates. http://rt.openssl.org/Ticket/Display.html?id=1942user=guestpass=guest -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Tue, Jun 02, 2009 at 01:25:32PM +0100, David Woodhouse wrote: On Mon, 2009-06-01 at 17:15 -0400, Victor Duchovni wrote: I found another strange behaviour that I didn't expect -- the _order_ of the certificates in the cafile seems to be important. Yes, the TLS protocol requires the trust chain to be delivered bottom-up. That makes sense, but we're talking about the order of the certificates in the cafile, not on the wire. OpenSSL really ought to get that right. The CAfile is for verification, not for sending alon the trust chain of a given certificate. DO NOT append your CAfile to your certificate, instead include just the leaf cert, then the issuing CAs bottom-up in the right order. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Sun, May 31, 2009 at 10:13:59AM +0100, David Woodhouse wrote: That makes a certain amount of sense; thanks. Forgive my ignorance -- is there a way to ensure that the full trust chain is included in the certificate itself, rather than having to provide the -CAfile option to openssl(1) separately? I na??vely tried just appending the contents of a working cafile to the certificate.pem file but that's not sufficient. Yes, you contcatenate in a single file: --- BEGIN... client certificate bits --- END... --- BEGIN... intermediate CA certificate that signed the above certificate --- END... ... --- BEGIN... intermediate CA certificate that signed the above certificate --- END... --- BEGIN... optional root CA certificate that signed the previous certificate --- END... I found another strange behaviour that I didn't expect -- the _order_ of the certificates in the cafile seems to be important. Yes, the TLS protocol requires the trust chain to be delivered bottom-up. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Tue, 2009-05-26 at 11:21 -0400, Victor Duchovni wrote: The server is unhappy with the client certificate chain, and drops the connection if the client certificate trust chain does not verify. The same server is willing to accept clients with no certificates at all. The server is lame. Don't use it with client certificates that don't have a complete trust chain. That makes a certain amount of sense; thanks. Forgive my ignorance -- is there a way to ensure that the full trust chain is included in the certificate itself, rather than having to provide the -CAfile option to openssl(1) separately? I naïvely tried just appending the contents of a working cafile to the certificate.pem file but that's not sufficient. I found another strange behaviour that I didn't expect -- the _order_ of the certificates in the cafile seems to be important. My original scripts which interact with the company's internal PKI infrastructure would download a bunch of certificates separately and I would shove them all in a single file with a command line like: for a in *.crt ; do cat $a ; echo company-certchain.crt The resulting file would work, and allow me to connect to the server. So I modified the scripts to create one big file just the same... except that they'd be stored in the order that they were downloaded, instead of alphabetical order by filename as the above shell command gave me. And _that_ cafile doesn't work; I still get summarily disconnected. Does ordering in trustchain files matter? If so, how do I ensure I get the right order? -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Sun, 2009-05-31 at 10:13 +0100, David Woodhouse wrote:
On Tue, 2009-05-26 at 11:21 -0400, Victor Duchovni wrote:
The server is unhappy with the client certificate chain, and drops the
connection if the client certificate trust chain does not verify. The
same server is willing to accept clients with no certificates at all.
The server is lame. Don't use it with client certificates that don't
have a complete trust chain.
That makes a certain amount of sense; thanks. Forgive my ignorance -- is
there a way to ensure that the full trust chain is included in the
certificate itself, rather than having to provide the -CAfile option to
openssl(1) separately? I naïvely tried just appending the contents of a
working cafile to the certificate.pem file but that's not sufficient.
I found another strange behaviour that I didn't expect -- the _order_ of
the certificates in the cafile seems to be important. My original
scripts which interact with the company's internal PKI infrastructure
would download a bunch of certificates separately and I would shove them
all in a single file with a command line like:
for a in *.crt ; do cat $a ; echo company-certchain.crt
The resulting file would work, and allow me to connect to the server.
So I modified the scripts to create one big file just the same... except
that they'd be stored in the order that they were downloaded, instead of
alphabetical order by filename as the above shell command gave me. And
_that_ cafile doesn't work; I still get summarily disconnected.
Does ordering in trustchain files matter? If so, how do I ensure I get
the right order?
I implemented PKCS#12 support in the OpenConnect VPN client¹, and
created a PKCS#12 version of my certificate including the required trust
chain -- by appending the full trust chain file to my certificate.pem
file and then running:
openssl pkcs12 -export -out cert.p12 -in cert.pem -inkey priv-key.pem
It only works if I reverse the order of the certificates it contains,
with a patch like the following:
diff --git a/ssl.c b/ssl.c
index 6f47568..3a8170c 100644
--- a/ssl.c
+++ b/ssl.c
@@ -163,7 +163,12 @@ static int load_pkcs12_certificate(struct openconnect_info
}
if (ca) {
+ STACK_OF(X509) *ca2 = sk_X509_new_null();
+
while ((cert = sk_X509_pop(ca))) {
+ sk_X509_push(ca2, cert);
+ }
+ while ((cert = sk_X509_pop(ca2))) {
char buf[200];
X509_NAME_oneline(X509_get_subject_name(cert), buf,
sizeof(buf));
I tried sk_X509_sort(ca) but that just segfaults...
--
dwmw2
¹ http://git.infradead.org/users/dwmw2/openconnect.git
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Mon, May 25, 2009 at 08:41:29PM -0400, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of David Woodhouse Sent: Friday, 22 May, 2009 05:49 To: openssl-users@openssl.org Subject: Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL. On Thu, 2009-05-21 at 22:44 +0100, David Woodhouse wrote: I'm trying to connect to an HTTPS server, and my connection is being rejected when I use a client certificate: [dw...@macbook ~]$ openssl s_client -cert $CERT -connect $SERVER:443 -crlf -tls1 CONNECTED(0003) depth=1 /C=US/O=Foo Corporation/CN=Foo Intranet Basic Issuing CA 2A verify error:num=20:unable to get local issuer certificate verify return:0 24620:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: Those errors are run together; there should be different line breaks. I've discovered that it works if I also use the '-CAfile' option and give it the appropriate certificate chain. If I use an empty CAfile or one with the wrong certificates in it, the server still hates me. I don't understand why you got verify return 0 above. In at least all 098* that I've used, s_client logs verify errors on the server cert (like no-issuer or self-signed) but ignores them and continues. However, since s3_pkt:530 is a failure on our end of the handshake, maybe it is indeed failing for verification. Or maybe something else, since according to your wireshark it certainly does seem the client sends the rest of the sequence (cert, keyxch, verify, change, finished?). I suggest running the client with -state and -msg or probably better -debug to get (much) more detailed information about what it's doing. And check (or ask) if the server logs any helpful error messages. The server is unhappy with the client certificate chain, and drops the connection if the client certificate trust chain does not verify. The same server is willing to accept clients with no certificates at all. The server is lame. Don't use it with client certificates that don't have a complete trust chain. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
From: owner-openssl-us...@openssl.org On Behalf Of David Woodhouse Sent: Friday, 22 May, 2009 05:49 To: openssl-users@openssl.org Subject: Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL. On Thu, 2009-05-21 at 22:44 +0100, David Woodhouse wrote: I'm trying to connect to an HTTPS server, and my connection is being rejected when I use a client certificate: [dw...@macbook ~]$ openssl s_client -cert $CERT -connect $SERVER:443 -crlf -tls1 CONNECTED(0003) depth=1 /C=US/O=Foo Corporation/CN=Foo Intranet Basic Issuing CA 2A verify error:num=20:unable to get local issuer certificate verify return:0 24620:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: Those errors are run together; there should be different line breaks. I've discovered that it works if I also use the '-CAfile' option and give it the appropriate certificate chain. If I use an empty CAfile or one with the wrong certificates in it, the server still hates me. I don't understand why you got verify return 0 above. In at least all 098* that I've used, s_client logs verify errors on the server cert (like no-issuer or self-signed) but ignores them and continues. However, since s3_pkt:530 is a failure on our end of the handshake, maybe it is indeed failing for verification. Or maybe something else, since according to your wireshark it certainly does seem the client sends the rest of the sequence (cert, keyxch, verify, change, finished?). I suggest running the client with -state and -msg or probably better -debug to get (much) more detailed information about what it's doing. And check (or ask) if the server logs any helpful error messages. I assume your $CERT file actually contains cert AND KEY, otherwise you should have gotten quite different errors. But NSS can connect without having to have the certificate chain in place locally. Is there a way to make OpenSSL behave similarly, so that it doesn't upset the server? Presumably it's not verifying the server, then. That's a local choice and doesn't bother the protocol. It's usually not good security practice; whether it's acceptable in your application is up to you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
On Thu, 2009-05-21 at 22:44 +0100, David Woodhouse wrote: I'm trying to connect to an HTTPS server, and my connection is being rejected when I use a client certificate: [dw...@macbook ~]$ openssl s_client -cert $CERT -connect $SERVER:443 -crlf -tls1 CONNECTED(0003) depth=1 /C=US/O=Foo Corporation/CN=Foo Intranet Basic Issuing CA 2A verify error:num=20:unable to get local issuer certificate verify return:0 24620:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: I've discovered that it works if I also use the '-CAfile' option and give it the appropriate certificate chain. If I use an empty CAfile or one with the wrong certificates in it, the server still hates me. But NSS can connect without having to have the certificate chain in place locally. Is there a way to make OpenSSL behave similarly, so that it doesn't upset the server? -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
TLS compatibility problem -- can connect to server with NSS but not OpenSSL.
I'm trying to connect to an HTTPS server, and my connection is being rejected when I use a client certificate: [dw...@macbook ~]$ openssl s_client -cert $CERT -connect $SERVER:443 -crlf -tls1 CONNECTED(0003) depth=1 /C=US/O=Foo Corporation/CN=Foo Intranet Basic Issuing CA 2A verify error:num=20:unable to get local issuer certificate verify return:0 24620:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: Making the _same_ connection with curl (built to use NSS) is working. Looking at a packet capture, the only obvious difference I see is in the structure of the packet which we send with our client certificate. Looking at the OpenSSL traffic in wireshark, it looks like this: - Secure Socket Layer - TLSv1 Record Layer: Handshake Protocol: Certificate - Secure Socket Layer - TLSv1 Record Layer: Handshake Protocol: Client Key Exchange - TLSv1 Record Layer: Handshake Protocol: Certificate Verify - TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec - TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message The one from NSS that _works_ looks like this: - Secure Socket Layer - TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages - Handshake Protocol: Certificate - Handshake Protocol: Client Key Exchange - Handshake Protocol: Certificate Verify - Secure Socket Layer - TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec - TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message Is it possible that the server would be objecting to the fact that the Certificate/Client Key Exchange/Certificate Verify messages from OpenSSL aren't all in the same TLSv1 record? There's another distinction which I don't understand -- why is wireshark grouping TLSv1 records under 'Secure Socket Layer' heading, and how does it decide where one 'Secure Socket Layer' object ends and the next one starts? I've given a screenshot of wireshark's display at http://david.woodhou.se/handshake.png in case the above description doesn't do it justice. The working connection with NSS is on the right; the failing connection with OpenSSL is on the left. This happens for me with 0.9.8f, 0.9.8k and 1.0.0-beta2 at least; I didn't try any more versions. The server is some Cisco VPN box, but for the purpose of this discussion it's just an HTTPS server (and firefox works with it too). When I _don't_ use a client certificate, I can connect fine -- of course I can't authenticate, but at least the HTTP exchange works well enough to tell me to sod off. It's only when I use a certificate that it will reject my connection completely. I get an ACK to my packet described above, then a FIN. That's it. The certificate in both cases is the same. -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
