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(00000003)
write to 0x983a0f8 [0x983f918] (121 bytes => 121 (0x79))
0000 - 80 77 01 03 01 00 4e 00-00 00 20 00 00 39 00 00 .w....N... ..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 ................
0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80 @...............
0050 - 00 00 03 02 00 80 00 00-ff 51 9f 89 53 62 47 7e .........Q..SbG~
0060 - 51 04 ce ae 50 f0 11 2e-24 ab 0b c2 21 c0 40 1d Q...P...$...!.@.
0070 - a7 7f 04 9e 5d 17 68 d3-1f
read from 0x983a0f8 [0x9844e78] (7 bytes => 7 (0x7))
0000 - 16 03 01 08 91 02
read from 0x983a0f8 [0x9844e7f] (2191 bytes => 1341 (0x53D))
[certificate data cut]
read from 0x983a0f8 [0x98453bc] (850 bytes => 850 (0x352))
[certificate data cut]
depth=2 /C=US/O=****/OU=****/CN=****
verify return:1
depth=1 /C=US/O=****/OU=****/CN=****
verify return:1
depth=0 /C=US/O=****/OU=****/CN=****
verify return:1
write to 0x983a0f8 [0x984efa0] (107 bytes => 107 (0x6B))
0000 - 16 03 01 00 66 10 00 00-62 00 60 28 7f 36 ed 73 ....f...b.`(.6.s
0010 - ce 2a 9c a0 4b df c8 48-77 7b e2 a8 1a 02 d9 7e .*..K..Hw{.....~
0020 - b5 98 89 2a c4 64 7e 87-41 52 bb 87 3b 4e 64 67 ...*.d~.AR..;Ndg
0030 - 7d a0 33 1d f3 d6 10 ad-b9 f7 60 1e 09 d2 19 6e }.3.......`....n
0040 - 87 2d f3 85 74 c0 9b 34-8b 74 3c 35 f6 2b 22 3e .-..t..4.t<5.+">
0050 - 9a 89 af f2 7d 77 dc c0-53 d5 11 60 87 0d 23 16 ....}w..S..`..#.
0060 - 62 a2 91 7b c1 08 b7 73-8e e7 b1 b..{...s...
write to 0x983a0f8 [0x984efa0] (6 bytes => 6 (0x6))
0000 - 14 03 01 00 01 01 ......
write to 0x983a0f8 [0x984efa0] (45 bytes => 45 (0x2D))
0000 - 16 03 01 00 28 cd 71 2d-47 b4 b7 25 c4 19 26 f3 ....(.q-G..%..&.
0010 - 24 10 42 b4 ab 88 97 46-ca ee f7 1c 31 92 84 47 $.B....F....1..G
0020 - 74 30 bf f3 d7 6f 83 f8-b0 76 5a 4e e8 t0...o...vZN.
read from 0x983a0f8 [0x9844e78] (5 bytes => 5 (0x5))
0000 - 15 03 01 00 02 .....
read from 0x983a0f8 [0x9844e7d] (2 bytes => 2 (0x2))
0000 - 02 50
20486:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal
error:s3_pkt.c:1086:SSL alert number 80
20486:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
