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 use by 's_client' and must
be split into at least into '-cert' (which can contain a private key;
typically not recommended) and the use of '-CAfile' is optional.
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?
When using the 'x509' utility in OpenSSL in conjunction with the
'-issuer -noout' flag(s) and verify it against the client certificate of
yours, does the output match that of a valid Client CA Issuer Name
provided by whomever you're trying to auth. against?
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)
Hope this helps.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
