SSL and public key security

Question

I am using a web service from an Android device using HTTP with SSL. For client authentication , a self-signed (untrusted) certificate is used.

I have a general idea of ​​how public / private keys are used for SSL. In my opinion, I can clearly see how a certificate can be used to securely connect and transfer data. However, I do not understand how they are used to authenticate the client, because the certificate contains a public key and is not kept secret.

I have a few questions:

Where can I learn about how to use SSL and certificates for client authentication?

Even if the certificate has not been published ... by visiting the HTTPS URL in the browser, I can view and save the certificate. Then I can pack the certificate in the keystore and use it from the application.

In this post, Jeremy Huikamp writes

client auth will automatically execute when the server requests this

... so can client authentication as well as data encryption be performed with certificates?

Edited to answer the first part of my question: the client keystore should contain not only the server’s public key, but also the client’s private key . Then the server should be able to decrypt using the client’s public key? Does this mean that the keystore must have two certificates?

Answer 1

First, a brief point of terminology in public key cryptography:

• you sign and decrypt / decrypt using the private key,
• you verify (signature) and encrypt / encrypt using the public key.

(You do not decrypt using the public key.)

Using SSL / TLS with or without client authentication, the server presents a certificate (*) for which it has a private key. The server sends its certificate during the SSL / TLS connection establishment (at the beginning of the connection) and can decrypt what the client sends using its private key (which it keeps confidential). The private key and certificates are stored in the keystore (or equivalent, if it is not implemented in Java).

As part of this, the client uses its trusted network, which is a keystore that contains trusted certificates, to verify the server’s certificate. A server certificate can be trusted if it is explicitly specified in a trusted store or, in most cases, trusted by reference to a trusted CA certificate in a trusted store (PKI).

The terminology between the keystore and truststore in Java can be a bit confusing, you can find more details in this answer .

As for your question, the client power of attorney does not contain the public key of the server, but either its certificate or CA certificate, with which it must be verifiable. (This is not just having a public key, but also knowing it, using other parts of the information in the certificate.)

If you use client certificate authentication in addition to this, there is a trust store (or its equivalent) on the server side and a client-side keystore, because for this purpose the roles are reversed.

In an SSL / TLS confirmation using client authentication, the server requests a certificate from the client that sends it (if available).

At the end of this handshake, the client sends a CertificateVerify message, which signs all the messages exchanged so far between the client and the server (so this is what both know) using the client’s private key certificate. The server can then verify this signature against the public key in the client certificate that it received as part of this exchange. This proves to the server that the one on the client side has a private key corresponding to the public key in the sent certificate.

The next step for the server is to check whether to trust this certificate, i.e. trust the binding between the identifier and the public key as presented and "sealed" in the certificate. This is usually done using PKI, through which you verify the certificate against a known CA, or if your deployment environment is small enough, against a fixed set of trusted certificates. (There may be alternative verification methods , but their usability will really depend on the conditions in which you want to deploy this system.)

Therefore, for your second question:

• Client client storage should contain at least a client certificate and its private key.
• In the trusted client store, the server certificate or CA certificate must be specified with which you can verify the server certificate.

Since both the keystore and the trust store are the keystore (in terms of the storage format, usually a file) used for another purpose, you can often use the same keystore to serve both the keystore and the trust store.

(*) There are cipher suites that do not rely on certificates, but this is unusual and not relevant to the subject.

Answer 2

The certificate simply associates the identity with the public key. This commitment is not a secret, so there is no need to keep a secret certificate. If I have a John Smith certificate, I can prove that John Smith owns a secret key corresponding to a particular public key. But since I do not know this secret key, the certificate is useless to me.

When authentication occurs with a certificate, the one who presents the certificate must always have one step, proving that he knows the secret key corresponding to the public key of the certificate. If you cannot complete this step, authentication will fail.

The server key store must have a server certificate. The client keystore must have a client certificate. The client will present its certificate to the server, so the server will recognize the client’s public key in this way. (And vice versa).