One of my partners wanted to do client side SSL certificate authentication.

They wanted us to sign the certificate using a recognized CA.

I was under the impression that for client side SSL certificate authentication, using a self signed CA would do. However, they insisted that it should be done by a recognized CA. Is there such a thing?

  • What exactly are you asking about? – user1700494 Feb 26 '16 at 8:21

This question is better suited for http://security.stackexchange.com sister site.

Client-side certificates should not be signed by a recognized CA; more precisely, they should be signed by such root/intermediate that only ever signs what you trust to represent your clients.

Obviously public root belonging to a recognized CA does sign other certificates than your clients; signing a certificate with some Subject text (CN) is the same as trusting that whoever requested signing is entitled to act as that Subject. This means a recognized CA by its very nature 'trusts' much more Subjects than you would trust. In other words, your server needs to take extra care to distinguish the Subjects that you trust from all the bunch.

Publicly recognized certs are also an extra cost to buy and to renew.

While there could exist solutions by recognized CAs that fulfill your requirements, they would be always more costly, more complicated, and far less secure than signing on your own (with your own root, after your own process of client identity verification). It doesn't make any sense to me.

Even worse solution is to pay for public certificates, and then remove all the public roots from your trust store and only add specific end-client certificates one by one. This "compromise" simply joins the costs of both alternatives without any of their respective benefits.

Update Professionally I often cooperate with banks and PCI processors for e-commerce payments. Most often they require their own CAs for both server-side and client-side certificates and refuse to use publicly recognized CAs.


Most, if not all, Server certificates issued by a commercial CA are also suitable for client authentication. The challenge is that as you will need to distribute the certificate and key to the client it might create a security risk. Unless you are going to do machine to machine communication I would create a private CA suitable to issue only client certificate.

Commercial CAs will only issue a Server certificate for a valid DNS name you own. If you want to use this Server certificate for client authentication you will need to send the certificate and key to the end users. This is a security risk for the server that you used to request the certificate.

  • Even with a private CA you need to distribute the cert and key to each client. I agree that presents risk, but not that it is any greater using third-party signed certificates. – MadHatter Feb 26 '16 at 10:17
  • @MadHatter With both private and public CAs, your end-client application (if it's a fat client) could handle private key generation. In this case private key is never transferred anywhere, only the certificate. – kubanczyk Feb 26 '16 at 13:50
  • @kubanczyk that is true, and a fair point; the client could generate the keypair, then pass a CSR to central for signing. That gives you a whole different authentication problem, but I agree it's not a key-distribution problem. But the same idea could be used for publicly-signed certificates, so I maintain my underlying point: the risks are no different whether the signing is done with a third-party publicly-valid certificate or with a private CA. – MadHatter Feb 26 '16 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.