Question: 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?

Answer: 
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.
*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.