Why would a client need our CSR file?

Question

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-

internal - to be used internally for integration purposes with the other departments in our organisation like Siebel CRM...
partner - for organisations with which we do business.
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-

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?

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 05 '20 at 08: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 05 '20 at 08:14
The point is that there is a difference by what CA certificate is issued: trusted one or not trusted — Alexander Fadeev, May 05 '20 at 08: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 05 '20 at 08:34

score 2 · Accepted Answer · answered May 06 '20 at 07:01

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.

answered May 06 '20 at 07:01

Pedro

3,911
11
25

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 06 '20 at 07: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 06 '20 at 08: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 06 '20 at 09: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 06 '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 06 '20 at 10:44
I think at this point myself and @dave_thompson_085 are just speculating around what is what to be used how and where. It's your ops team who can narrow down these details for you. Because we lack a lot of context. Also, I suggest you prop-up your knowledge of TLS including how it achieves integrity, confidentiality and mutual-authentication assurances and how that maps into PKI (public key infrastructure). – Pedro May 06 '20 at 21:07
Thanks, both of you. – Farhan Shirgill Ansari May 06 '20 at 21:22

Why would a client need our CSR file?

1 Answers1