> 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. 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
