A Public Key Certificate is a document. We can use it to share a public key directly with other users/people/services. It is also known as a digital certificate or identity certificate. Basically, a certificate tells someone else, that you own a certain public key. That public key can then be used to start a secure communication (encrypt messages).
How does it work?
The first step in creating a certificate is to send your public key to a Public Key Authority (a.k.a. certificate authority). Then, the certificate authority creates the public key certificate and return it to the user.
A second user that gets this certificate, can validate against the certificate authority that the certificate is valid.
After the previous step, the second user can encrypt a message with the public key and send it in a secure way. Only the holder of the corresponding private key will be able to decrypt the message.
X.509 Certificates
X.509 is a standard that defines public key certificate structure and authentications protocols. As a standard, it is used in several applications and services. For instance, in emails and secure protocols like SSL and TLS.
Applications of public-key certificates
Nowadays browsers and web servers are very easy to use and configure. Someone without knowledge of computing can just open a web browser on a cellphone and open a web page or application.
However, the underlying software becomes more complex with time. On one hand, you see the browser providers increasing the functionalities and therefore the complexity of maintaining the software, and on the other side, hackers trying to exploit vulnerabilities on servers and browsers.
Three main threats that web applications face are:
- Integrity: Modification of user data.
- Confidentiality: theft of data, loss of privacy.
- Authentication: impersonation and data forgery.
The three previous threats can be prevented using cryptographic techniques.
Let’s see below two examples of applications of digital certificates to secure web communication.
SSL/TLS
Secure Sockets Layer (SSL) is a protocol that enables secure communication over the network. Transport Layer Security (TSL) is the successor of SSL, and it is a standard defined in RFC 5246. Both protocols rely on the TCP protocol.
We can use these protocols in two ways: Provided as part of the software implementation, for instance, browsers have them included, or just using them as part of the underlying communication protocol.
The protocol has several layers, one of them, specify what are the cryptographic algorithms supported by the client and the key exchange algorithm.
With the above, all the communication can be encrypted, and therefore secure, without user intervention.
Website security (HTTPS)
HTTPS or, HTPP over SSL, is the use of the HTTP and SSL protocols together to encrypt communication between a web browser and web server.
HTTPS is already built-in in web browsers. Therefore, it is transparent to web applications. In short, this means you can create your web application without any consideration on how to transmit the information in a secure/encrypted way. At a later stage, you can configure your server to use HTTPS and as a result, all the communication between a client (usually a web browser) and the server will be encrypted and secure.
To use HTTPS, you should have a valid digital certificate on the server. If the certificate is valid and the user requests the HTTPS URL, you should see a padlock next to the URL like in the image below.
If you click on the padlock icon, you can see the details of the certificate.
Example of a public key certificate
Find below an example of a digital certificate.
The web browser already has code included that can check if the digital certificate is valid or not. It will check that the name on the certificate is the same as the domain name. Another important check is the date. The certificate has two dates, not valid before and not valid after. The browser will check if the current date is between the two dates on the certificate.
All the details of the certificate are specified as per the X509 standard. All the code to understand and check if the certificate is valid or not is embedded on the web browser.
A browser can show that a certificate is not valid, or give a warning, depending on the Certificate Authority (CA). In the example, the CA is Let’s Encrypt. If the CA is compromised, a web browser can show a warning on the certificates that are issued by that CA. Sometimes it might not be fair, but that is how it works in practice.
How do I verify if a certificate is valid?
You don’t need to verify the certificate yourself. The web browser or any other application that uses a certificate will do it for you.
However, if you still want to do it yourself you can check it out against the standard X.509.
If you want to do an “eagle view” checkup, you can check the following:
- The name (common name) should be the same as the domain name.
- The date must be valid. Check the two dates provided on the certificate against the current date.
- The name of the issuer must be trusted.
- The algorithm used for encryption must be a standard.
You can check the previous information and more on the certificate.
If you have the certificate on your computer, you can verify if it is valid using the openssl console application. Open a terminal/console in the folder where you have the certificate and run the following command:
openssl verify -CAfile trusted-ca-certificate.pem certificate-to-verify.pem
How do I get a certificate?
You can get a certificate through a Certificate Authority (CA).
There are many CAs, some free some paid. Here I’ll list three of them, but feel free to explore.
- Let’s Encrypt (free).
- DigiCert (paid).
- Google Trust Services (“At this time, the only way to get a certificate from Google Trust Services is via an Alphabet or Google product.”).
Creating your own digital certificate with openssl
Openssl is a command-line tool that provides a toolkit for general purpose cryptography and secure communication.
See the below step-by-step guide to create a self-signed digital certificate.
Create the CA certificate
As you should remember, certificates are created by a Certificate Authority (CA). So, we need to create the (root) certificate for our own CA.
openssl req -x509 -newkey rsa:4096 -days 365 -keyout ca-private-key.pem -out ca-certificate.pem
Create the server certificate
The server certificate is our certificate. Notice that we create a certificate to share it with other people, so they know how to securely communicate with us.
openssl req -newkey rsa:4096 -keyout server-key.pem -out server-request.pem
Sign the server certificate
openssl x509 -req -in server-request.pem -CA ca-certificate.pem -CAkey ca-private-key.pem -CAcreateserial -out server-certificate.pem
Verify the certificate
As the last step, you can verify if the new certificate is valid or not.
openssl verify -CAfile ca-certificate.pem server-certificate.pem
You can also view the certificate in “text mode” with the following command.
openssl x509 -in server-certificate.pem -noout -text
When you run the previous command, you can verify if all the data you provided is right. Like the common name. You can also check the issuer, which in this case is the same as the details in the CA certificate you just created.
Difference between a public key certificate and a digital signature
The difference is that a public key certificate (or digital certificate) shares a public key, and it is used to establish a secure communication channel with the owner of the public key. In other words, establish a mechanism to know if the owner of that public key is really who claims to be the owner and the public key is used to encrypt the communication.
On the other hand, a digital signature is a mechanism we can use to verify the authenticity of a message/document. It is usually needed in situations when there is no trust between sender and receiver. You can read more about digital signatures in this post.
Related topics: