1

If I have a cert that has the usages:

  • Server Authentication (1.3.6.1.5.5.7.3.1)
  • Client Authentication (1.3.6.1.5.5.7.3.2)

Is it possible that if a client accesses the server and was sent a copy of the cert that they could use that cert as the client auth?

I have a web application that has a cert with server and client auth.

The server does not block client access to the URL. The client can access https://my.app. When the client accesses https://my.app/Service it should be blocked. This is configured in that app. In this case the app is letting the client in with out explicitly installing that cert on the client machine.

I'm trying to figure out if that's because the client previously accessed the root url and established an SSL connection.

Could this be possible?

2 Answers 2

4

Beware of terminology. Certificates relate to asymmetric cryptography in which keys go in pairs: each pair contains a public key and a private key, which are two facets of the same underlying mathematical object (which depends on the algorithm type). Crucially, the private key cannot be computed from the public key, which is exactly why the public key can be made public.

The certificate contains the public key -- only the public key. When a SSL client connects to a SSL server, the server sends its certificate to the client, but certainly not the corresponding private key. Instead, the server uses its private key to perform an operation that only the server can do (because that operation requires the private key and the private key is private).

Similarly, when a SSL client connects to a SSL server and the server asks for a "client certificate", it really means that the client will send its own certificate (with the client public key) and will demonstrate its mastery of the corresponding private key by performing an operation that can only be done with the private key (but can be verified with the public key); this is a signature.

In your envisioned scenario, a client C connects to a first server S1, and S1 sends to C a copy of its certificate. Then C connects to a second server S2 that asks for a "client certificate". C may send the certificate that it received from S1, but that won't go far because C does not have access to the corresponding private key: that key never left server S1, the client does not have any access to it. Thus, C won't be able to complete the authentication with server S2.

The exact extra markings in the certificate (client auth, server auth...) are merely supplementary restrictions on certificate usage, but they are not the foundation of the cryptographic security here. What matters is that a certificate contains only a public key, not the corresponding private key.

0

My understanding is of your question is that you ask if the client can use the servers certificate to authenticate against the server, because the client got this certificate within the TLS handshake with the server. If this understanding is correct then the answer is NO because:

  • Only the certificate is send within the TLS handshake, but not the private key matching the certificate. This key is kept secret by the server. But only the party which knows the matching secret key can identify/authenticate itself using a certificate.
  • Even if the client somehow knows the private key for the servers certificate the server will probably not accept it for authentication because the server expects the client to be identified as client and not as server, i.e. different subjects in the certificate.

You must log in to answer this question.

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