RE: Client certificate chains
> From: owner-openssl-us...@openssl.org On Behalf Of plot.lost > Sent: Tuesday, 22 March, 2011 02:12 > On 22/03/2011 09:24, Crypto Sal wrote: > > Me thinks they don't understand Client Authentication/Digital > > Certificates. The server doesn't typically need to verify up to the > > root, they provide a list of acceptable client CA names during the > > handshake. > > Yes and no. The server MAY specify desired client CAs in CertRequest, but OpenSSL client ignores this and uses whatever is configured as "own" key+cert. OpenSSL *server* can easily be misconfigured to solicit client certs that it doesn't trust and vice versa. And what any verifier does is its own choice. OpenSSL as verifier does always verify up to root, even if an intermediate CA cert is in the truststore; there have been several discussions in the past few months (here or -dev, I forget) about whether this is good. > >> I'm using a CAfile that has all of the certificates in - > as far as I > >> am aware that makes openssl trust these certificates. > >> CAfile is for you=client trusting the server, which is completely separate from the server trusting you. > > > > Do you have them in reverse hierarchy when using '-CAfile' > > ?(Intermediate(s) to Root) I have seem some > systems/programs flip out > > because certificates were out of order. > > > Yes, they are in the usual order, with root as the final cert. > > -CAfile/load_verify_locations order doesn't matter. use_certificate_chain_file, for the certs you=client send to the server, order does or at least may matter. > Those running the server are the ones that signed the client > certificate > and provided the CA and Root certificates that are in use. > Okay, then they really should be trusting themselves! > == Info: SSLv3, TLS handshake, Server finished (14): > <= Recv SSL data, 4 bytes (0x4) > : 0e 00 00 00 > == Info: SSLv3, TLS handshake, Client key exchange (16): > => Send SSL data, 102 bytes (0x66) > : 10 00 00 62 00 60 45 1d e4 bd 03 4e bb 10 f1 04 ...b.`EN > 0010: 72 4f 1f 2d 0e ea 7d d4 37 ee 4b a0 3f 27 33 26 rO.-..}.7.K.?'3& > 0020: 33 10 06 82 4b 66 c0 ca aa 14 68 6a f8 00 0d 89 3...Kfhj > 0030: 17 92 4e ed 84 eb 82 52 e8 59 39 fe 81 4b 7c 10 ..NR.Y9..K|. > 0040: e7 db 6e 54 2c 4e de 34 ff 8f 11 8e 5d 3e 5d e3 ..nT,N.4]>]. > 0050: 41 09 b4 06 36 78 cd 4b 33 c2 ce e4 06 a4 19 97 A...6x.K3... > 0060: 5d bf 88 69 02 c8 ]..i.. > == Info: SSLv3, TLS change cipher, Client hello (1): > => Send SSL data, 1 bytes (0x1) > : 01 . > == Info: SSLv3, TLS handshake, Finished (20): > => Send SSL data, 16 bytes (0x10) > : 14 00 00 0c 94 4e 6d 82 d8 f2 8b a0 0f 30 61 b3 .Nm..0a. > == Info: SSLv3, TLS alert, Server hello (2): > <= Recv SSL data, 2 bytes (0x2) > : 02 50 .P > == Info: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert > internal error > == Info: Closing connection #0 > > I don't think they list any specific ca as part of the client cert > requests, I think they rely on the client providing a full > certificate As I said before, they *must* be configured with at least the root(s). They *cannot* trust (and must ignore) any root the client supplies. You must always supply your user cert, and prove its key. Whether you need to supply any intermediate certs (between you and root) varies. > chain and they then validate that using some other method. It > seems that > for some reason openssl is not sending any certificate to them. > Yes, you=client is definitely not sending the Cert (and CertVerify). Are you sure the server is sending the CertRequest? It should be just BEFORE the server "finished" (handshake 20 is really server_done). If the server doesn't send CertRequest, OpenSSL client mustn't and doesn't send any cert, and DOESN'T treat this as an error. Ooh, one thing I forgot before: does the TYPE of your key (in privatekey file and your cert) -- RSA, DSA/DH, ECDSA/DH -- match the negotiated ciphersuite? If not, OpenSSL musn't and won't use the cert for client auth. (And if the server demands client auth, it will reject, although as I have said before, "internal error" is a poor way for it to do so.) If the server is configured to agree to many (or all?) ciphers (and servers often are) you may need to _set_cipher_list to a more restricted set, or at least an ordering which puts your preference first. > This seems to be something specific to TLS1.1 - see: > > http://lists.foaf-project.org/pipermail/foaf-protocols/2009-Fe > bruary/000264.html > Not really. This is only if you *don't* have a requested cert, and IIRC the change is to send a Cert message with no cert (zero-length sequence) as opposed to no Cert message at all. The semantics, and the resulting trust decision, is the same. __
Re: Client certificate chains
On 22/03/2011 09:24, Crypto Sal wrote: Me thinks they don't understand Client Authentication/Digital Certificates. The server doesn't typically need to verify up to the root, they provide a list of acceptable client CA names during the handshake. I'm using a CAfile that has all of the certificates in - as far as I am aware that makes openssl trust these certificates. Do you have them in reverse hierarchy when using '-CAfile' ?(Intermediate(s) to Root) I have seem some systems/programs flip out because certificates were out of order. Yes, they are in the usual order, with root as the final cert. My thoughts... When you connect using 's_client' do you use something similar to the following? `openssl s_client -connect FQDN:PORT -cert CERT_FILE -key KEY_FILE -CAfile yourCAfile` Have you tried just to connect to the site without the '-cert', '-key' and/or '-CAfile' and see if any useful information is presented by the server or does the connection fail outright? Without the -CAfile then the connection to the server fails at the server certificate stage (self-signed cert). With the CAfile but without cert/key then the connection fails at the same point as if the cert/key had been provided. Based on the error of 'SSL alert number 80', that you have provided previously, I suspect the problem is with your certificate's (client cert) issuing CA being unknown to the server (one that it doesn't directly trust and you need an appropriate hierarchy) Those running the server are the ones that signed the client certificate and provided the CA and Root certificates that are in use. == Info: SSLv3, TLS handshake, Server finished (14): <= Recv SSL data, 4 bytes (0x4) : 0e 00 00 00 == Info: SSLv3, TLS handshake, Client key exchange (16): => Send SSL data, 102 bytes (0x66) : 10 00 00 62 00 60 45 1d e4 bd 03 4e bb 10 f1 04 ...b.`EN 0010: 72 4f 1f 2d 0e ea 7d d4 37 ee 4b a0 3f 27 33 26 rO.-..}.7.K.?'3& 0020: 33 10 06 82 4b 66 c0 ca aa 14 68 6a f8 00 0d 89 3...Kfhj 0030: 17 92 4e ed 84 eb 82 52 e8 59 39 fe 81 4b 7c 10 ..NR.Y9..K|. 0040: e7 db 6e 54 2c 4e de 34 ff 8f 11 8e 5d 3e 5d e3 ..nT,N.4]>]. 0050: 41 09 b4 06 36 78 cd 4b 33 c2 ce e4 06 a4 19 97 A...6x.K3... 0060: 5d bf 88 69 02 c8 ]..i.. == Info: SSLv3, TLS change cipher, Client hello (1): => Send SSL data, 1 bytes (0x1) : 01 . == Info: SSLv3, TLS handshake, Finished (20): => Send SSL data, 16 bytes (0x10) : 14 00 00 0c 94 4e 6d 82 d8 f2 8b a0 0f 30 61 b3 .Nm..0a. == Info: SSLv3, TLS alert, Server hello (2): <= Recv SSL data, 2 bytes (0x2) : 02 50 .P == Info: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error == Info: Closing connection #0 I don't think they list any specific ca as part of the client cert requests, I think they rely on the client providing a full certificate chain and they then validate that using some other method. It seems that for some reason openssl is not sending any certificate to them. This seems to be something specific to TLS1.1 - see: http://lists.foaf-project.org/pipermail/foaf-protocols/2009-February/000264.html Is this behaviour that is not supported by openssl, or am I going down the wrong track (again...) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client certificate chains
On 03/22/2011 12:09 AM, plot.lost wrote: Or do you simply mean you looked manually at the x509 output (probably -text) and it looks correct to you? Yes, using -text to manually check the chain. Have you confirmed this alert is in response to your cert? You can use s_client with -debug, or run a network monitor (I recommend www.wireshark.org on Windows) to see. And are the server people actually looking at the error they got on your attempt(s), or just guessing? I think they are just using a pre-set response to any questions regarding connectivity problems, it's that same basic response that comes back each time. Verifying you-the-client is indeed the job of the server. And if doesn't verify you, then it would better give a more specific alert, like 'unknown CA' or 'invalid cert', not 'internal error'. Do you know what kind of software the server is running -- at the protocol level especially, e.g. if it is 'Apache plus our-bus-app' you probably only care about 'Apache', maybe 'Apache mod_ssl version N'. Somehow I don't think I would get a meaningful answer to this question... There are three common problems in this area but none quite matches what you relay the server people said. 1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs (client and/or server, and/or other kinds) directly under a root, but most have a multi-level hierarchy: root signs level2, level2 signs user; or level2 signs level3 and level3 signs user, etc. Each SSL system, such as this server, is configured with a set of CA-certs it knows (and trusts), but that set may not go all the way down. If that is the case, your client must supply the remaining 'intermediate' cert(s) during handshake. If you have the complete chain for your cert, or you get it from the CA(s), you could try showing it (probably Issuer, Serial, Subject, SubjectKeyID if any, AltName extensions if any, and CRLDistPoint or AuthorityInfoAccess extensions if any) to the server people and ask them to identify which cert(s) they don't already know (if any). Then give that/those to SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file. Or at worst supply everything; the server should ignore any it doesn't need, and it just takes a tiny bit longer. However, the server must already trust the root, at least; even if you supply the root, they can't trust that. See 3. 2. Ambiguous CA(s). A CA can have multiple (issuing) certs for the same name. In this case a verifier, like this server, needs to know which issuing cert (and hence key) to use. The standard way of doing this is an extension AuthorityKeyID abbreviated AKID in the user cert. If this is needed the CA should have done it, and if the CA didn't you can't fix it. x509 -text will show whether it is there, and if so help you build (or verify) the chain as above. 3. Wrong CA. Possibly the server simply doesn't trust the CA you used, although when you say 'required authority' I assume you mean required *by the server people*. s_client or monitor as above will show if the server is specifying 'preferred' CA(s) in its CertRequest message. If it is, and your cert is not under that or one of them (possibly though intermediates as above), that may be the problem. But note that OpenSSL for one configures the 'preferred' CA(s) separately from the "trusted" CA(s), so a mismatch with this field isn't definitive. I've tried generating a pkcs12 file that contained the client certificate, ca, root and client key and sent this to them. They have confirmed that it is valid. I hope you 'sent' it to them in a secure fashion or else at least consider that key/cert pair 'compromised'. ;) The last response had "it seems that our server could not trust the certificate and failed to open the output stream at your end to pass the data" which does not make any sense to me. Again they say "import all of the certificates to your certificate trust store" Me thinks they don't understand Client Authentication/Digital Certificates. The server doesn't typically need to verify up to the root, they provide a list of acceptable client CA names during the handshake. I'm using a CAfile that has all of the certificates in - as far as I am aware that makes openssl trust these certificates. Do you have them in reverse hierarchy when using '-CAfile' ?(Intermediate(s) to Root) I have seem some systems/programs flip out because certificates were out of order. For the cert option I've tried PEM encoded files that have just the client cert in, one that has client and ca, and one with client, ca and root. I've also tried these by converting the pkcs12 back to pem, which added some extra bits before each certificate section, none of these have made any difference. Can the pkcs12 file be used directly by s_client - the docs I have show that only PEM and DER are supported? Does it support having this chain of certificates in the client cert file? As far as I am aware PKCS12 files can not be u
Re: Client certificate chains
On 22/03/2011 08:09, plot.lost wrote: Or do you simply mean you looked manually at the x509 output (probably -text) and it looks correct to you? Yes, using -text to manually check the chain. Have you confirmed this alert is in response to your cert? You can use s_client with -debug, or run a network monitor (I recommend www.wireshark.org on Windows) to see. And are the server people actually looking at the error they got on your attempt(s), or just guessing? I think they are just using a pre-set response to any questions regarding connectivity problems, it's that same basic response that comes back each time. Verifying you-the-client is indeed the job of the server. And if doesn't verify you, then it would better give a more specific alert, like 'unknown CA' or 'invalid cert', not 'internal error'. Do you know what kind of software the server is running -- at the protocol level especially, e.g. if it is 'Apache plus our-bus-app' you probably only care about 'Apache', maybe 'Apache mod_ssl version N'. Somehow I don't think I would get a meaningful answer to this question... There are three common problems in this area but none quite matches what you relay the server people said. 1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs (client and/or server, and/or other kinds) directly under a root, but most have a multi-level hierarchy: root signs level2, level2 signs user; or level2 signs level3 and level3 signs user, etc. Each SSL system, such as this server, is configured with a set of CA-certs it knows (and trusts), but that set may not go all the way down. If that is the case, your client must supply the remaining 'intermediate' cert(s) during handshake. If you have the complete chain for your cert, or you get it from the CA(s), you could try showing it (probably Issuer, Serial, Subject, SubjectKeyID if any, AltName extensions if any, and CRLDistPoint or AuthorityInfoAccess extensions if any) to the server people and ask them to identify which cert(s) they don't already know (if any). Then give that/those to SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file. Or at worst supply everything; the server should ignore any it doesn't need, and it just takes a tiny bit longer. However, the server must already trust the root, at least; even if you supply the root, they can't trust that. See 3. 2. Ambiguous CA(s). A CA can have multiple (issuing) certs for the same name. In this case a verifier, like this server, needs to know which issuing cert (and hence key) to use. The standard way of doing this is an extension AuthorityKeyID abbreviated AKID in the user cert. If this is needed the CA should have done it, and if the CA didn't you can't fix it. x509 -text will show whether it is there, and if so help you build (or verify) the chain as above. 3. Wrong CA. Possibly the server simply doesn't trust the CA you used, although when you say 'required authority' I assume you mean required *by the server people*. s_client or monitor as above will show if the server is specifying 'preferred' CA(s) in its CertRequest message. If it is, and your cert is not under that or one of them (possibly though intermediates as above), that may be the problem. But note that OpenSSL for one configures the 'preferred' CA(s) separately from the "trusted" CA(s), so a mismatch with this field isn't definitive. I've tried generating a pkcs12 file that contained the client certificate, ca, root and client key and sent this to them. They have confirmed that it is valid. The last response had "it seems that our server could not trust the certificate and failed to open the output stream at your end to pass the data" which does not make any sense to me. Again they say "import all of the certificates to your certificate trust store" I'm using a CAfile that has all of the certificates in - as far as I am aware that makes openssl trust these certificates. For the cert option I've tried PEM encoded files that have just the client cert in, one that has client and ca, and one with client, ca and root. I've also tried these by converting the pkcs12 back to pem, which added some extra bits before each certificate section, none of these have made any difference. Can the pkcs12 file be used directly by s_client - the docs I have show that only PEM and DER are supported? Does it support having this chain of certificates in the client cert file? Below is the output when trying to connect - I've had to obscure the certificate details from the server but that stage verifies ok, and is using the same CA/Root as the client cert is using. CONNECTED(0003) write to 0x983a0f8 [0x983f918] (121 bytes => 121 (0x79)) - 80 77 01 03 01 00 4e 00-00 00 20 00 00 39 00 00 .wN... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00 ..3..2../... 0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00
Re: Client certificate chains
Or do you simply mean you looked manually at the x509 output (probably -text) and it looks correct to you? Yes, using -text to manually check the chain. Have you confirmed this alert is in response to your cert? You can use s_client with -debug, or run a network monitor (I recommend www.wireshark.org on Windows) to see. And are the server people actually looking at the error they got on your attempt(s), or just guessing? I think they are just using a pre-set response to any questions regarding connectivity problems, it's that same basic response that comes back each time. Verifying you-the-client is indeed the job of the server. And if doesn't verify you, then it would better give a more specific alert, like 'unknown CA' or 'invalid cert', not 'internal error'. Do you know what kind of software the server is running -- at the protocol level especially, e.g. if it is 'Apache plus our-bus-app' you probably only care about 'Apache', maybe 'Apache mod_ssl version N'. Somehow I don't think I would get a meaningful answer to this question... There are three common problems in this area but none quite matches what you relay the server people said. 1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs (client and/or server, and/or other kinds) directly under a root, but most have a multi-level hierarchy: root signs level2, level2 signs user; or level2 signs level3 and level3 signs user, etc. Each SSL system, such as this server, is configured with a set of CA-certs it knows (and trusts), but that set may not go all the way down. If that is the case, your client must supply the remaining 'intermediate' cert(s) during handshake. If you have the complete chain for your cert, or you get it from the CA(s), you could try showing it (probably Issuer, Serial, Subject, SubjectKeyID if any, AltName extensions if any, and CRLDistPoint or AuthorityInfoAccess extensions if any) to the server people and ask them to identify which cert(s) they don't already know (if any). Then give that/those to SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file. Or at worst supply everything; the server should ignore any it doesn't need, and it just takes a tiny bit longer. However, the server must already trust the root, at least; even if you supply the root, they can't trust that. See 3. 2. Ambiguous CA(s). A CA can have multiple (issuing) certs for the same name. In this case a verifier, like this server, needs to know which issuing cert (and hence key) to use. The standard way of doing this is an extension AuthorityKeyID abbreviated AKID in the user cert. If this is needed the CA should have done it, and if the CA didn't you can't fix it. x509 -text will show whether it is there, and if so help you build (or verify) the chain as above. 3. Wrong CA. Possibly the server simply doesn't trust the CA you used, although when you say 'required authority' I assume you mean required *by the server people*. s_client or monitor as above will show if the server is specifying 'preferred' CA(s) in its CertRequest message. If it is, and your cert is not under that or one of them (possibly though intermediates as above), that may be the problem. But note that OpenSSL for one configures the 'preferred' CA(s) separately from the "trusted" CA(s), so a mismatch with this field isn't definitive. I've tried generating a pkcs12 file that contained the client certificate, ca, root and client key and sent this to them. They have confirmed that it is valid. The last response had "it seems that our server could not trust the certificate and failed to open the output stream at your end to pass the data" which does not make any sense to me. Again they say "import all of the certificates to your certificate trust store" I'm using a CAfile that has all of the certificates in - as far as I am aware that makes openssl trust these certificates. For the cert option I've tried PEM encoded files that have just the client cert in, one that has client and ca, and one with client, ca and root. I've also tried these by converting the pkcs12 back to pem, which added some extra bits before each certificate section, none of these have made any difference. Can the pkcs12 file be used directly by s_client - the docs I have show that only PEM and DER are supported? Does it support having this chain of certificates in the client cert file? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Client certificate chains
> From: owner-openssl-us...@openssl.org On Behalf Of plot.lost > Sent: Monday, 21 March, 2011 11:44 > I am having problems connecting to a system that requires a client > certificate. Generated the csr using the relevant openssl commands and > sent that to the required authority for signing. That has come back as a > valid certificate (can use openssl x509 to verify the certificate 'x509' only checks that a cert is validly encoded (formatted). It doesn't check that the cert is correctly signed by the issuer, or if it's revoked, if it's expired only if you specifically ask, or if it permits this type of usage namely SSL -- although if the CA issued it to you as an SSL-client cert, they should get that right. 'verify' does the signature/chaining and purpose checks, revocation for plain-old-CRLs(?), and expiration (which shouldn't be a problem for newly-issued, but in some cases, especially if someone gets a timezone wrong, you might attempt to use a newly-issued cert that is BEFORE its validity period, and that's also an error). Or do you simply mean you looked manually at the x509 output (probably -text) and it looks correct to you? > content), but using that certificate does not allow the connection to > complete (fails with 'error:14094438:SSL > routines:SSL3_READ_BYTES:tlsv1 > alert internal error' ) > > According to the people that run the server I am trying to connect to, > the problem is that my certificate 'does not have the chaining setup. > The Root and CA should be trusted' > That combination doesn't really make sense. Note that 'root' and 'CA' are different, although related. Have you confirmed this alert is in response to your cert? You can use s_client with -debug, or run a network monitor (I recommend www.wireshark.org on Windows) to see. And are the server people actually looking at the error they got on your attempt(s), or just guessing? > Does this mean that somehow I am supposed to include these as part of > the client certificate? If so, how do I do this? Does it instead mean > that I should somehow be passing the CA/Root into openssl to allow it to > verify the client as part of the connection? (which makes no sense to > me, why would the client need to verify it's own certificate > - that must be the servers job) > Verifying you-the-client is indeed the job of the server. And if doesn't verify you, then it would better give a more specific alert, like 'unknown CA' or 'invalid cert', not 'internal error'. Do you know what kind of software the server is running -- at the protocol level especially, e.g. if it is 'Apache plus our-bus-app' you probably only care about 'Apache', maybe 'Apache mod_ssl version N'. > I was under the impression that the CA and Root would be held by the > server and that it would use those to verify the client certificate I am > presenting, but it seems not to be the case according to them. Can > anyone shed any light on this? > There are three common problems in this area but none quite matches what you relay the server people said. 1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs (client and/or server, and/or other kinds) directly under a root, but most have a multi-level hierarchy: root signs level2, level2 signs user; or level2 signs level3 and level3 signs user, etc. Each SSL system, such as this server, is configured with a set of CA-certs it knows (and trusts), but that set may not go all the way down. If that is the case, your client must supply the remaining 'intermediate' cert(s) during handshake. If you have the complete chain for your cert, or you get it from the CA(s), you could try showing it (probably Issuer, Serial, Subject, SubjectKeyID if any, AltName extensions if any, and CRLDistPoint or AuthorityInfoAccess extensions if any) to the server people and ask them to identify which cert(s) they don't already know (if any). Then give that/those to SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file. Or at worst supply everything; the server should ignore any it doesn't need, and it just takes a tiny bit longer. However, the server must already trust the root, at least; even if you supply the root, they can't trust that. See 3. 2. Ambiguous CA(s). A CA can have multiple (issuing) certs for the same name. In this case a verifier, like this server, needs to know which issuing cert (and hence key) to use. The standard way of doing this is an extension AuthorityKeyID abbreviated AKID in the user cert. If this is needed the CA should have done it, and if the CA didn't you can't fix it. x509 -text will show whether it is there, and if so help you build (or verify) the chain as above. 3. Wrong CA. Possibly the server simply doesn't trust the CA you used, although when you say 'required authority' I assume you mean required *by the server people*. s_client or monitor as above will show if the server is specifying 'preferred' CA(s) in its CertRequest message.
