Imagine we have two companies, A (our) and B, both having some web-services. Company A uses company's B web service and vice versa. All web services are secured with server SSL certificates, and client SSL certificates are used for authentification.

For testing purposes our company (A) issued a self-signed server certificate and a corresponding client one, both signed by our standalone CA, which was added to trusted root CA's on server and clients.

Now we need to go real world and we ordered a server certificate from GoDaddy. How do we get corresponding client certificate? Company B wants a new client certificate, which would be signed with trusted CA, because "it makes sure that private keys remain where they should be".

They sent a CSR, what should I do with it? How do I issue a trusted client certificate using it?

The interesting fact is that Company B uses certificates issued by Company B Standalone CA, but browser shows it as valid (i.e. green), although I didn't add any intermediate CA's to my trusted root authorities. The certification path of such certificate doesn't contain any well-known CA's like Thawte, Verisign, etc. How is that possible?

1 Answer 1


There is no implicit linkage between the certificate(s) a client uses to authenticate a server, and those a server uses to authenticate a client.

It's perfectly possible for the clients to authenticate the server using a trusted-third-party-issued certificate, such as the one you now have, while the server continues to authenticate the clients using a private CA. It's also possible for the server to authenticate those same clients using a public certificate bundle. But if you want the latter to apply, you can't sign those CSRs; they must go off to GoDaddy (or some other trusted third-party) as well, each one, and be signed.

So I'm afraid the answer is it depends. If your server is still configured to use a private CA root to authenticate the clients, then you should go on signing the CSRs with that private root. The clients can continue to authenticate the server using a public bundle and the server's new third-party certificate; there is nothing wrong with that model. If, however, you have reconfigured your server to use a public certificate bundle to authenticate the clients, then each client will need a trusted-third-party-signed certificate, and you will have to get used to paying for those.

As for how you see a green bar, it may be because you have at some past time imported their CA root as a valid signing certificate, or it may be that it's not signed privately, but publicly. It is impossible to say without sight of the certificate in question.

  • As far as I see GoDaddy (and many others) can only issue certificates which verify FQDN. But we need to issue a client certificate, should we specify our web-service url as FQDN for this certificate? Jun 17, 2014 at 11:55
  • It depends. How is the server set up to do the verification of the clients? Whatever it is looking for, that you will need to provide.
    – MadHatter
    Jun 17, 2014 at 11:58
  • Client certificates are checked with web-service code. Basicly we only verify certificate thumbprint. I mean, will CA be able to issue a certificate without specifying a FQDN? Jun 17, 2014 at 12:08
  • What do you mean by "we only verify certificate thumbprint"? Do you mean that the server maintains a database of acceptable certificate fingerprints, and verifies the client(s) against that? I'm ignoring the second half of your response above as I'm not yet convinced it's relevant.
    – MadHatter
    Jun 17, 2014 at 12:11
  • Yes, we have a database of acceptable certificate fingerprints and server code verifies clients against that. Jun 17, 2014 at 12:15

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.