2

I am having trouble understanding the concept of X509 encryption and its application to web service communication.

The situation is that I (client) would like to communicate with another party (server) securely. To do this, the client obtains an X509 certificate from a trusted third-party CA (certificate authority). In this certificate, there is a public key (given by the CA which can be validated by the server to come from CA) shared between client and server and there is a private key which is stored locally on the client.

From my understanding, the only use for the X509 certificate is to verify that a message from client to server can be verified by the server to have come from the client through a digital signature, and there is no encryption that is performed on the message content aside from that required for signing.

For instance, if the client is consuming SOAP web services on the server, then the private key on the client is used to add a digital signature to the request headers which can then be verified on the server, after which point the request is fulfilled.

Please let me know if I am understanding this correctly.

1

Welcome to security.stackexchange.com. I think you have a few misunderstandings of how certificates are created, issued, served, and verified.

the client obtains an X509 certificate from a trusted third-party CA

No. The client obtains the certificate from the server when it connects to the server by https.

In this certificate, there is a public key given by the CA which can be validated by the server to come from CA)

No. The CA does not issue the public key. To do that, the CA would also have to know the private key, which would mean that it is no longer private. Only the server knows the private key.

and there is a private key which is stored locally on the client.

In most cases, No. Unless the client is using a client certificate (which is not very common) the client does not store a long-term private key, like the server does.

Let's clarify the above before we move on. Here's how it works: The server creates a key pair (consisting of a private key and a corresponding public key). Then the server creates a certificate signing request (CSR), which contains information about the server (such as the FQDN of the server), and the public key. The server then sends the CSR to a CA, and the CA creates a certificate from the CSR and signs the certificate. The CA signature on the certificate is to indicate that the CA verified the the server 'is who it says it is' (how they do this is another questions). Then, the CA sends the signed certificate back to the server. At this point, the CA is no longer involved.

When a client connects to the server by https, the server sends the certificate. The client checks that the certificate is signed by a CA that the client trusts, and if so, the client proceeds with TLS, using the server's public key contained in the certificate. Importantly, in order for the TLS connection to succeed, the server must have the private key that corresponds with the public key in the certificate.

From my understanding, the only use for the X509 certificate is to verify that a message from client to server can be verified by the server to have come from the client through a digital signature, and there is no encryption that is performed on the message content aside from that required for signing.

No. SSL/TLS provides the three fundamentals needed for any encryption system: secrecy, authenticity, and integrity. Messages sent between the client and the server are encrypted, so that someone monitoring the traffic between the client and the server only sees ciphertext and not plaintext messages (secrecy). In addition, SSL/TLS provides a way for one party to ensure that a message indeed came from the other party (authenticity), and that the message was not altered along the way by an attacker (integrity).

For instance, if the client is consuming SOAP web services on the server, then the private key on the client is used to add a digital signature to the request headers which can then be verified on the server, after which point the request is fulfilled.

I think you might be thinking of client certificates here. Client certificates can be used to authenticate a client with a server. See Using client certificate to authenticate an app for more info.

5
  • Your description coincides with my understanding of https connections between a client (browser) and server with server side authentication (e.g. stackexchange.com), but the situation I was considering was when a client acquires a cert which is used to authenticate on a web server. The basic workflow is that the client signs a message with a local private key, which can then be authenticated by the webserver. The webserver then responds with an access token, and the authentication process is complete. The public and private key is issued by a trusted third party which is the CA. Feb 25 at 1:40
  • I may be mistaken, but I believe that the public key shared from the client to the server can be verified by the server to have come from the CA. Does this workflow make sense? Feb 25 at 1:44
  • I think what you are referring to is a client certificate. This works basically the same way as a server certificate, but in reverse, and the role of the CA is the same. Also, the message is not signed by the client, it is hashed using an HMAC function. But, the server can authenticate that the message came from the client.
    – mti2935
    Feb 25 at 2:26

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.