• 8

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191


File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

Sign client certificate with trusted CA

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?


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.

  • 1
Reply Report
    • 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?
      • 1
    • 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.
    • 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?
    • 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.

Trending Tags