What's a client certificate and where to get it, how to use it to connect to server?

Question

I am writing an client application in c++ to retrieve some information from the server via https, but the server requests client certificate for authentication, I know how the server certificate works during web browsing via https: the public certificate is served to any web browser which come with an extensive built-in list of trusted root certificates that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site, but I'm not unclear about the client certificate.

I've googled a lot, but still confused. Could anyone explain it to me? And where can I get the client certificate? From the server? I know I can load the certificate file by calling SSL_CTX_use_certificate_chain_file() and load the private key by calling SSL_CTX_use_PrivateKey_file in openssl if I have the client certificate and the client private key.

Answer 1

First, We should know the Private Key/Public Key:

The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite, you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key!

Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message

One of the problems left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his public key as well as a certificate.

How do you know that you are dealing with the right person or rather the right web site. Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path. Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself, it is called a self signed certificate. All root CA certificates are self signed.

Client certificates:

Client certificates are issued to a user by a certification authority. They consist of the public key portion of the certificate and a private key that is held only by the entity to which the certificate is issued. The certification authority may be a well-known public organization that provides certificate services as part of its business, or it could be an internal server that only your company uses. In either case, the client certificate will have certain information that identifies the user either individually or as part of a group. They are meant for authenticating the client to the server. For example, you can create a self-signed client certificate just like a server certificate:

openssl req -nodes -new -x509 -keyout clientkey.pem -out clientreq.pem -days 365 -config openssl.cnf

Answer the necessary questions, then sign it:

openssl x509 -x509toreq -in clientreq.pem -signkey clientkey.pem -out tmp.pem

openssl ca -config openssl.cnf -policy policy_anything -out clientcert.pem -infiles tmp.pem 

Then you can try to connect to the server with client certificate:

openssl s_client -connect host:443 -cert clientcert.pem -key clientkey.pe -state -quiet

One important detail with clients certs (certs in general) is that is can be exported and most implementations do not lock down portability of the cert. Regardless of whether or how the client certs are going to be stored, without proper measures, the cert can be easily copied from device to device. Some implementations store the cert on the filesystem (files that end with .cer, .der, .key, .crt usually are indications that certs are stored in the filesystem). Stronger implementations (application dependent) may store the certs and keys in a keystore (i.e. java key store). The key store can add additional protection like ensuring the private key is not exportable. However, the assurance that the key hasn't been exported is only as strong as the key store itself. Hardware key stores (i.e. smart cards, usb hsm, ironkey, etc) offer a much stronger assurance that private key is not exportable than software key stores.

Answer 2

A client certificate is used in 2-way, or mutual SSL connections. The normal SSL connection that you described in your question is 1-way SSL...the client browser is authenticating the server.

In 2-way SSL, the server needs to authenticate the client as well. Therefore, the client needs a certificate.

One example of this scenario is when the company/entity that owns the server wants to control who connects to it. Therefore, they issue client credentials to those they trust to connect to it. These credentials can take the form of USB eTokens, soft keys, etc. If soft keys, these can be generated on the client machine, with the CSR sent to the server owner (or server-trusted CA), which in turn can sign the Cert and send it back to the client.