3

I'm trying to integrate with a 3rd party service and they have requested our server's public key. I've sent it to them and they said they have configured it on their end. In order for me to make requests to them, they claim I must include the certificate with the request.

How exactly does this scheme work? I don't see how a Diffie-Hellman exchange can work in this case. Any scheme I think of can easily be broken in the case of a MITM. We have no way of generating the secret and sending it to them securely like a standard handshake. But if they generate the secret, how can they send it back and prove it was them who generated it?

I am using cURL so I assume they want me to make the request with the --cert flag (includes public and private key).

--cert tells curl to use the specified client certificate file when getting a file with HTTPS, FTPS or another SSL-based protocol. The certificate must be in PKCS#12 format if using Secure Transport, or PEM format if using any other engine. If the optional password isn't specified, it will be queried for on the terminal. Note that this option assumes a "certificate" file that is the private key and the client certificate concatenated.

Improve this question
1
  • 1
    Are you familiar with 2-way SSL (AKA: mutual auth ssl)? This sounds like a fairly standard use of it.
    – Neil Smithline
    Commented Nov 17, 2015 at 15:58

2 Answers 2

Reset to default
6

This is TLS Mutual Authentication.

It is a proven and well-documented part of TLS and happens during handshake.

Nothing unusual is happening and the handshake is specified to fail if you do not supply the client certificate.

MitM is definitely still a concern, but that is mitigated for you as a client by CA trust and signing (or certificate pinning) on your side and by similar CA trust (or client certificate pinning) on the server side. Someone supplying a forged certificate from a MitM position will need to be CA signed or to social engineer one side or the other into pinning their malicious certs.

IMPORTANT: you MUST provide the client cert (if not CA signed) in a secure manner to the server operator. In-band key exchange is certainly not up to this task. One option is to publish the cert on a secured HTTPS endpoint for a domain you own from which the server operator can download the cert with confidence that it is from you and hasn't been tampered with in transit. This has its flaws (incompetent CAs, server compromise, etc.), but it should be sufficient for most cases.

There's a good description of the process here: http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

Improve this answer
0

The scheme works as follows:

By showing that you can encrypt or decrypt a message with your private key you authentificate yourself to the third party.

Because your public key is public, the third party is not authentificated.

When you are using https in your requests, you get a certificate that authentificates the third party as well.

Of course, you also establish an encrypted (secure) communication channel as well.

Improve this answer
1
  • That makes sense assuming we are connected through their SSL. Trying to hit the endpoint without passing a certificate through results in handshake errors, which is why I'm unsure of the scheme. I guess it's possible that will be negotiated after I validate myself.
    – James E
    Commented Nov 17, 2015 at 9:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .