0

I am a beginner to TLS/Ops.

Our operations team have setup a number of virtual hosts with domains we own for hosting endpoints on our Cloud.

We have 3 virtual hosts-

  1. internal - to be used internally for integration purposes with the other departments in our organisation like Siebel CRM...
  2. partner - for organisations with which we do business.
  3. public - as the name suggests

All communication is over TLS.

There is a new partner to whom we(I am a developer) have exposed a new API.

When a developer from their team tries to consume our API with Postman, all he gets is -

Client Certificate is not trusted in this subdomain and/or this endpoint explicitly

Their postman console shows this as seen in the attached image-

enter image description here

In the communication which our OPS team had with the client OPS team, I see that our Ops requested for a CSR file from the client and vice versa.

From the web, I see that a certificate signing request (CSR) is one of the first steps towards getting your own SSL Certificate.

Why would a client need our CSR file and similarly why would our Ops need theirs?

4
  • Seems like they need to issue a new client certificates using those CSRs using proper CA certificate, so that a new client certificate would be trusted in subdomains – Alexander Fadeev May 5 '20 at 8:07
  • I read that a SSL cert is issued by a CA. Furthermore, if a client is giving their cert to us, what does their cert has to do with our CSR? I fail to comprehend this. – Farhan Shirgill Ansari May 5 '20 at 8:14
  • The point is that there is a difference by what CA certificate is issued: trusted one or not trusted – Alexander Fadeev May 5 '20 at 8:30
  • If it is not issued by a CA, then is a self-signed certificate. But what does their cert has to do with our CSR? – Farhan Shirgill Ansari May 5 '20 at 8:34
2

If I understood correctly, your peer's client-side certificate is not trusted by your organisation. Your ops team would have asked for a CSR to return a signed certificate that you trust, so that their (new) client-side certificate becomes trusted. Unless there's more involved that isn't clear in the question, you don't need to send them a CSR, since your peer would not need to sign certificates for you.

About the CSR: To have a certificate signed, you need to have a key pair (private and public keys) and issue a certificate signing request (CSR) which contains bits of information and your public key. The CSR is handed over to the CA who in turn produce and return a signed certificate file for you (also containing your information, your public key and a signature).

Conversely, but less likely, if the 'client certificate' term in the error message is misleading, this could mean that your org's server side certificate isn't trusted by your peer's client software. This is where they may be asking you to change your server side certificate, hence why your ops could have decided to do initiate that by sending them your CSR.

7
  • Thanks Pedro. After the client has sent his CSR, in response to this our OPS created a .cer file and handed over to this particular client. Is the client going to put these cert(created by ours OPS) into his truststore so that he can validate the cert when the communication happens. And is this the same cert our server will give as part of the initial request involved in TLS? – Farhan Shirgill Ansari May 6 '20 at 7:11
  • 2
    Shirhill: no. the client will use the cert your people issued, with the key the client itself previously generated, in their keystore, namely the PFX file obscured in the screenshot you posted. The client system will use that key and send that cert to authenticate themselves, which your server will validate, and as a result will accept the requests from that client. (Or at least no longer reject them for this reason; there may be other checks/requirements as well.) – dave_thompson_085 May 6 '20 at 8:07
  • 1
    @dave_thompson_085 is correct. The case here is that your client has a client-side certificate (used by their client software) that isn't being trusted by your server. It's your server that is rejecting the connection, not their software. So the solution was for your org to issue a new client-side certificate to your client (from their CSR) that they will use to connect to your service. In turn your server will establish a TLS connection with their software if it accepts the client-side certificate (which should now be trusted). – Pedro May 6 '20 at 9:04
  • @Pedro As observed by me, the cert issued to the client by us when decoded with an online tool, it had both the client information as well as information related to our company. For another client calling the same API, a separate cert would need to be generated, and so on for each and every client. Is my understanding correct? – Farhan Shirgill Ansari May 6 '20 at 10:43
  • @dave_thompson_085 Thanks. You said that client will use the cert issued by us with the key the client itself previously generated. For what purpose was this key and what it has to do with the cert issued by us? – Farhan Shirgill Ansari May 6 '20 at 10:44

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.