10

I'm looking for some clarification around the trust requirements (if any) of client certificates.

I'm working with a third party to access their services via Mutual TLS.

I generate a CSR, send it to the third-party, they send me a certificate (which they've generated using their own CA). It's a single certificate. I haven't been provided with any intermediate certificates - as I'm assuming you don't need these to issue client certificate authenticated requests.

When I attempt to connect with this certificate, I get a handshake failure: 

openssl s_client -connect the-server.com:443 -cert the-cert.pem -key the-key.pem -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write certificate verify A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read finished A
78460:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_pkt.c:1145:SSL alert number 40
78460:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s23_lib.c:185:

I'm being told that it's failing as: 'the pem files do not contain the public CA certs that signed the client certificate' however if this was the case, would the client even send the certificate (as it appears to be doing so in the TLS negotiation steps above) if it was the case that it needed to trust it?

Improve this question
3
  • Does 'using their own CA' = internal CA? If yes does the server you are connecting to have their CA's certificate installed (so that it knows to trust the client certificate you are presenting)? Just a thought.
    – R15
    Nov 11, 2015 at 14:12
  • 1
    Yes - it's an internal CA, and you could be right about the lack of trust on their end - what I'm trying to establish is whether there's any validity in the claim that client certificates need to have the certificate chain (on the client), or present this certificate chain with the certificate, in order to be authenticated.
    – Mark Kelly
    Nov 11, 2015 at 14:23
  • If you can't get good answers from the human(s), add -debug to s_client (or in trunk with a custom build -trace) or use Wireshark or similar and look at the contents of the server's certificate-request message. If it specifies a root CA like Fleebnitz Corp Global CA and your cert's Issuer name is Fleebnitz Application #3 blond-haired-users CA, you need some intermediate(s). If your cert's issuer name is Fleebnitz Inc Worldwide CA then somebody messed up your cert issuance or the server config or both.
    – dave_thompson_085
    Nov 11, 2015 at 19:08

3 Answers 3

Reset to default
9

Do client certificates need to be trusted by the client?

No, the client certificate is only validated by the server and the server certificate only by the client. Thus any kind of trust regarding the client certificate or its signing CA is only needed at the server.

... It's a single certificate, with no intermediate

... the pem files do not contain the public CA certs that signed the client certificate

I would suggest that the first statement is wrong, i.e. that the certificate you got was actually signed by an intermediate CA and you did not include the necessary chain certificates. The root certificates itself should not be send because these have to reside as trusted at the side which is doing the validation, i.e. the server in case of client certificates.

I would suggest that you'll find out which CA they have as pre-trusted at the server side and compare this with the issuer of your certificate. If they don't match then chain certificates are missing. If they match than it might be a problem with the setup on the server side, i.e. that they don't have the necessary CA configured as trusted by the server for client authentication.

Improve this answer
2
  • Let me clarify the single certificate statement: What I've received - from the third party - is a single certificate with no accompanying chain (hope that makes sense). When you say 'The root certificates itself should not be send because these have to reside as trusted at the side which is doing the validation, i.e. the server in case of client certificates.' aren't we saying none of the certificate chain needs to be sent in a client authentication scenario (just the end certificate)?
    – Mark Kelly
    Nov 11, 2015 at 13:56
  • @MarkKelly: when I say the root certificate should not be sent I mean only the root certificate. All chain certificates must be sent, no matter if you received them or not. This is the same with client and server certificates. Chain certificates can only be omitted if the server knows them already and thus can built the trust chain to the root.
    – Steffen Ullrich
    Nov 11, 2015 at 14:24
4

No, the client doesn't need to trust the certificates it presents to the server. (The server doesn't need to trust the certificates it presents to the client either). Only the other side of the connection needs to be able to verify the presented certificates.

That being said, the private key and certificate used by the client MUST match. You can check that by using the following commands:

openssl rsa -in localhost.key -modulus -noout openssl x509 -in localhost.crt -modulus -noout Their output needs to match exactly.

The server may expect the client to send the intermediate CA certificate necessary to verify authenticity of the user certificate but that would be very weird and basically unheard of.

Finally, if you're deploying a new system I would very strongly suggest not to use OpenSSL 0.9.8 - it will be receiving security updates only till the end of the year.

Improve this answer
11
  • 1
    If the private key would not match the public key then the certificate and certificate verify would not have been sent by the client. But it was sent according to the handshake output. Also, the version of OpenSSL is irrelevant here and certificates created with OpenSSL 0.9.8 will work with later OpenSSL versions or other SSL stacks.
    – Steffen Ullrich
    Nov 11, 2015 at 13:50
  • 1
    @SteffenUllrich: Yes, the certification creation library doesn't matter (you can use GnuTLS to create than and use them with OpenSSL). But I somehow doubt that Mark has pulled out the old version of OpenSSL just to show the problem he's having. Finally, while new OpenSSL does check if your private key matches the cert (don't know about 0.9.8), the protocol itself doesn't care - you can sign the message with any key you want.
    – Hubert Kario
    Nov 11, 2015 at 14:25
  • I think Mark is using this old OpenSSL version because this is the one which comes installed with Mac OS X. I don't now if Apple will ever ship a newer version or if they will just abandon shipping OpenSSL at all because they have their own TLS stack.
    – Steffen Ullrich
    Nov 11, 2015 at 14:31
  • @HubertKario as Steffen suggests - this is the version of OpenSSL that ships with Mac OSX. Just to confirm, this version of OpenSSL doesn't let me use the wrong key.
    – Mark Kelly
    Nov 11, 2015 at 14:40
  • 1
    @MarkKelly: Then note that El Capitan completely deprecated OpenSSL: lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html
    – Hubert Kario
    Nov 11, 2015 at 15:04
1

Given that the client certificate is issued by an internal CA, the server that is being connected to will need to 'trust' the internal CA in order to be able to verify the client certificate.

Even if the client could present the internal CA's public certificate, the server will still not trust the certificate because it has not been signed by one of its trusted roots (i.e. one of the many public CAs...Verisign, Comodo etc.).

The server admins need to install the internal CA's certificate (i.e. the root for your client certificate) in the server's trust store.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .