4

I'm trying to put the finishing bits and pieces on a client / server application I'm writing, but something seems to go foul at the last step in the SSL handshake.

The client side of the program connects and establishes a secure connection with a server without a hitch, but if I want to run operations from the server side of the program, it fails to make any connection.

When I try to connect to my server via Firefox (as the client), the browser will alert to me that the certificate is not suitable for the connection.

On the server side, my logs reflect that there's an unknown ca or certificate unkown whenever I try to accept bytes from my client.

I guess my question boils down to this point:

Do you have to make different certificates for a client side application vs a server side application? What's the difference between these?

kelly.dunn
  • 143
  • 1
  • 4

3 Answers3

5

The same way that server certificates uniquely identify a server (or domain), client certificates uniquely identify a client. And just like server certificates must be signed by someone the client trusts, client certificates must be signed by someone the server trusts.

Usually, when you configure a server to accept client certificates, you specify a signing certificate that must be used to sign the client's cert. This lets the server know that the client is "authorized", whatever that might mean in your context, since presumably you'll only sign certificates for "authorized" users.

Allowing client certificates without doing any sort of verification is generally possible with most servers, but sort of defeats the whole purpose.

tylerl
  • 14,885
  • 7
  • 49
  • 71
  • Thanks @tylerl ! It seems like my application should be accounting for this~ Before accepting connections, I set the client CA list of the server to include Verisign (a widely trusted CA, I take it). I suspect that the certificate that I'm currently using is only signed by one CA (a private one). How would I go about creating a server certificate that's been signed by Verisign(or something that works in all browsers)? I can't seem to find this anywhere. – kelly.dunn Sep 13 '10 at 00:59
  • @kelly.dunn Note that the list of CA trusted by the server is completely independent of the CAs trusted by the client, so you can have a Verisign-certified cert for your server (as most clients will trust those by default) and choose to accept client certs from your own CA (for the clients to which you've emitted such certs). `CA.pl` which comes with OpenSSL (see `man CA.pl`) is a script that can help you create your own CA. – Bruno Sep 13 '10 at 18:56
  • @Bruno Thanks, this cleared up some residual confusion I had about "trusted CAs", my understanding has grown a bit since yesterday :D But now it seems odd, as I explicitly set the client CA list in my application to include my own trusted CAs. I've gotten past the "unknown ca" error, but the client still won't accept my server cerfiticate~ – kelly.dunn Sep 14 '10 at 18:40
  • 1
    It's not just about the CA list, but about the trust anchors (the actual trusted CA certs). These are distinct (the CA list in the SSL/TLS `CertificateRequest` message is in fact just a hint). If you look at how Apache Httpd does it, the list is configured via the `SSLCADNRequestFile` directive whereas the accepted CAs come from `SSLCACertificatePath/...File` (configuring `SSLCADNRequestFile` is normally not necessary as the CA DN list is auto-filled by the list of CAs by default. See this: http://stackoverflow.com/questions/3476288/client-ssl-with-self-signed-ca-not-working/3476512#3476512 – Bruno Sep 14 '10 at 19:06
  • @Bruno Many Thanks :D!! Your linked post was extremely helpful. After following your sage advice, my application does indeed list all the CAs I intended to use, but the errors *still* persist. Could this simply be because I'm not loading it correctly in my application? – kelly.dunn Sep 15 '10 at 18:26
3

It depends on the type of server certificate. Sometimes self-signed certs can be problematic. If it is signed by a Certificate Authority, generally the client certificate will also have to be signed by the same CA and may need the entire certificate chain included as well.

You can use openssl to gather some information on acceptable CAs for client certificates with the command line:

openssl s_client -connect host.domain.tld:443

or whatever port SSL is listening on. This should give information about the certificate chain all the way up to the root CA and also provide acceptable CAs for client certificates as well.

T.P.
  • 163
  • 5
  • Thanks @jtpresta ! I've used the utility before, but you explained it in such a way that it helped me understand what I have to do :D I realized that my program was only validating my client-side's certificates because it was connecting to a server using a private CA, which (Coincidentally) all of my other certificates were signed. – kelly.dunn Sep 13 '10 at 01:01
  • The comment about the client and server certificates being signed by the same CA isn't entirely accurate. The server certificate usually must be signed by a "commonly trusted" CA -- e.g. Verisign, Thawte, etc. The client cert must be signed by a CA trusted by the server, which is generally much more narrowly defined and application-specific, and may not include any of the "commonly trusted" CAs at all. – tylerl Sep 15 '10 at 22:48
  • @tylerl - I agree with you. Thank you for the clarification. The situation I described is a little more common in our shop. Both the servers and clients get signed by the same sub CA but include the entire chain up to the root CA. Additionally, we're generally required to export the client public cert for installation on the target server itself. Sometimes it is a lot of work getting all the parties coordinated :) – T.P. Sep 16 '10 at 06:28
1

jtpresta in one of his comments indirectly makes an interesting but very true point: SSL client authentication is a mess. It's good because it's absolutely secure, but it's crappy because it's difficult both to set up and to maintain.

Unless you have a really good reason, go with shared-key authentication instead (i.e. "password"). You'll save time and money. SSL authentication is good for when security trumps cost by a fairly wide margin.

tylerl
  • 14,885
  • 7
  • 49
  • 71