The term digital certificates and signatures are mentioned a lot within the world of IT. In this article, I will try to describe on a high level what digital certificates and digital signatures are, and how they are used.

To understand Digital certificates and signatures you need to understand encryption based on asymmetric keys, aka. Asymmetric encryption.

Asymmetric encryption is a method of encryption that works by having two encryption keys. When one of the keys is used to encrypt only the other can be used to decrypt the message. Both keys can be used for encryption and decryption, but the same key cannot be used for both encryption and decryption of the same message. This is a lot more complex than symmetric encryption that makes use of a single key to both encrypt and decrypt a message.

Because the same key that was used for encryption cannot be used for decryption, we can use one key to encrypt a message that only the person having the other key can decrypt. If only a single person has a copy of one of the keys, it's possible for many people to share the other key and use it to send encrypted messages to a single person that only that person can decrypt.

This is one of the main reasons why one of the keys is called a public key, and the other is called a private key. The public key can be given to anyone who wants to send an encrypted message to a specific person. The private key must be kept secret by that one person, and never be shared with anyone.

If I have your public key, and you have my public key we can securely communicate. I will encrypt a message using your public key, that only you can decrypt using your private key, and you can encrypt a message using my public key that only I can decrypt using my private key.

Because only one person has the private key we can use it to verify that a message was sent by that person by decrypting the message using the public key.

If you are able to decrypt a message that you received using my public key, you can be sure that it was encrypted using my private key. If you trust that only I have my public key you can be just as sure that the message was sent by me.

Public keys and private keys are often used as an alternative to a password when logging in to a server using SSH. Instead of providing a password the SSH client encrypts a message using the private key. If the SSH server is able to decrypt the message using the public key stored on the server you are authenticated, and is able to log inn. To read more about using this method of authentication read this norwegian article.

A digital signature is used to verify that data - like a word document - was created by a specific person and has not been changed after it was signed.

The digital signature is created by first creating a hash of the data that is to be signed. The hashing algorithm creates a fixed-length digest that represents the content of that data. If the data is changed in any way the hash will change completely. After the hash is created it is encrypted using the signee's private key.

The digital signature will be sent along with the message and can then be used to verify that the message was created by a specific person and that the document was not changed after it was signed. This is done by using the signees public key to decrypt the hash value to get the hash. The receiver then creates its own hash of the received message and compares that has to the decrypted hash from the sender. if the two hashes are identical we have verified that the file has not been modified after it was signed and that it was signed by the owner of the private key.

Digital certificates are used to make it easier to relate an encryption keypair with an owner. Much like a driver's license (certificate) is used to verify that the driver is allowed to drive a car, a digital certificate is used to verify that the public key belongs to a specific owner.

If you want to be sure that the person using the private key is who they say they are, you can make use of a third party to verify the owner of the private key. This is done using signed digital certificates.

A signed digital certificate is created for a person by sending the person's public key along with proof of identity to a Registration Authority (RA). The RA will perform a test to verify that the proof of identity is correct. If the test is passed, the RA will send the certification request to its Certificate Authority (CA). The CA will then encrypt the information that proves the identity of the person and the person's public key using the CA's private key.

A signed digital certificate is simply the information about the certificate owner and the owner's private key that has been encrypted using a CA's private key. By being able to use the CA's public key to decrypt the certificate with the CA's public key we can verify that the CA has verified the owner of the Certificate. Så if you trust the CA, you can trust that the certificate owner is who they say they are.

By using signed digital certificates we can ensure that we are not talking with an imposter that tries to fool us into thinking we are talking with the real person. It's impossible for anyone to modify the content of the digital certificate because they do not have the CA's private key.

A common application for signed digital certificates is when accessing web pages using HTTPS.

When you request a web page from www.haxor.no using HTTPS you will receive a signed digital certificate. This certificate is signed by the Certificate Authority (CA) Let's Encrypt. Using Let's encrypts public key, that is stored in every operating system and most web browsers the certificate can be decrypted. If the decryption succeeds the web browser has verified that the CA has checked that the certificate issued by www.haxor.no belongs to www.haxor.no. Because we trust Let's encrypt we can therefore trust that the public key that was contained within the certificate actually belongs to www.haxor.no

The browser will then generate a symmetric session key that will be used to encrypt all messages between the server and the client for the duration of the HTTPS session. This symmetric key will be encrypted using www.haxor.no's public key before it is sent to the webserver hosting www.haxor.no.

When the webserver receives the encrypted session key it will decrypt it using its private key, and send an acknowledgment to the client indicating that it received the session key. From then on the server and the client will encrypt all communication using the unique symmetric encryption session key.

HTTPS only uses asymmetric keys only during the initial phase because it requires a lot more processing time to encrypt and decrypt messages using asymmetric encryption compared to symmetric encryption.