Introduction to SSL Certificates

What is an SSL certificate?

SSL certificate is a digital certificate that proves the identity of a server (or a client) using a cryptographic infrastructure.

Using SSL certificate both clients (e.g browser) and servers are able to exchange encrypted traffic over the internet.

All browsers indicate when a server is using an SSL certificate - we can see a lock icon and an HTTPS prefix at the beginning of the URL.

Why do we need SSL certificates:

Till 2008 most websites did not serve certificates, they were serving pages over HTTP and the sessions were not encrypted. This causes a few issues -

1. Clients couldn't tell if the website they were communicating with is the website they requested. Imagine you are navigating to www.mybank.com, but a hacker is serving you a different website, which looks similar to your bank. Many users failed to these cyber tricks online, resulting in providing their secret credentials to malicious servers.

2. Hackers were able to intercept communication between clients and servers. Since the traffic was not encrypted, anyone with some knowledge and a sniffing tool could see their communication and get his hands on secrets and other personal data.

With an SSL certificate, the connection between clients and servers is trusted and secured. Clients are able to authenticate the websites and once they achieve that, they can proceed with encrypted communication over HTTPS.

We can click the lock icon in the URL bar in order to see the content of the certificate

We can see 3 certificates, from right to left -

1. Root CA certificate

2. Intermediate CA certificate

3. User certificate

*CA - Certificate Authority

All these 3 certificates make up the certificate chain - operational certificates will always come in the form of a chain, that’s due to the nature of the cryptographic infrastructure that is the basis for the whole PKI (Public Key Infrastructure) mechanism.

Here is how the cryptographic mechanism of the certificate works:

The user certificate is signed by an intermediate CA (Certificate Authority) certificate, and the intermediate certificate is signed by the Root CA certificate. The Root CA certificate itself is trusted and self-signed, indicating the top of the certificate chain.

Root Certificate

The root certificate is the Certificate Authority (CA) certificate.

Signing a certificate is just running a computer command, anyone can sign certificates (CSR - Certificate Signing Request) using the correct tool (OpenSSL is a very popular one), and since anyone can sign certificates, it makes the whole process useless, cause hackers can sign certificates for themselves, and this is where CA are coming in solving the issue. A certificate authority is a trusted authority, they are following strict rules and guidelines, and browsers, servers and OSs are trusting them. They do not trust certificates that were not signed at the top of the chain by a valid CA.

There are more than 100 trusted CAs, the popular ones are Sectigo, Digicert, Let’s encrypt…

Intermediate Certificate

The intermediate certificate is also a CA certificate, the CA are using them in order to avoid direct signing of user certificates with their trusted root certificate. This is done due to few reasons -

1. Each CA sells more than just one type of certificate, so they manage multiple intermediate certificates, each for every type

2. It will be much less complex to revoke an intermediate certificate than a root certificate. Both by the way are very problematic and CAs should never reach a point where they need to do so.

User certificate

The user certificate is the certificate that describes the server where the website is hosted. This certificate shows the details of the company, the proof of ownership of the domain, and more.

Certificate Details

Issuer - the owner issued the certificate, the one who signed it (the intermediate or the root certificate)

Subject - the owner of the current certificate

Validity Period - the validity period of the certificate

Subject Public Key and Subject Public Key Algorithm - the public key of the certificate, clients using it for signature validation and for TLS handshake

Subject Alternative Names (SAN) - these are the domains that are covered by the certificate. the owner of the certificate had to prove that he owns them.

Signature and Signature Algorithm - a signature is a private key cryptographic outcome that is used by the clients to validate using the public key of the certificate that the certificate was 100% sent from the server and not by someone else.

Finger Print and Serial Number - these are unique identifications to help manage certificates on online repositories such as OCSP (Online Certificate Status Protocol ) and revocation services.

Formats

Certificates come in a variety of formats - DER, PEM, PFX.

DER - a binary form. DER certificate can contain only one certificate - not a chain of certificates.

PEM - a textual form. same content of a DER certificate, but encoded in BASE64 with a head and a tail: ----BEGIN CERTIFICATE ---- and ----END CERTIFICATE ----

Using the head and the tail we get another capability - we can store multiple certificates in a single text file - the whole certificate chain. This format is very popular since it is much easier to handle a single text file than multiple binary files.

PFX - also known as PKCS12 or p12. This is a binary format that is capable of storing multiple certificates with their private keys, and protecting them with passwords. This format is also popular because it makes the handling of the certificate - private key pair much more secure.

Here is an example of a PEM certificate chain -

First certificate is the end-user certificate, the 2nd is the intermediate CA, and the last one is the root CA certificate.

-----BEGIN CERTIFICATE-----

MIIFQjCCBCqgAwIBAgISBGhzQ+BFwadinktNFWoqegp/MA0GCSqGSIb3DQEBCwUA

MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD

EwJSMzAeFw0yMjA4MDcwNDIyNTJaFw0yMjExMDUwNDIyNTFaMB0xGzAZBgNVBAMT

...

mj2amK8W6cRyTOzuGX/eoKoi5KqavfDvuVXIDfC7aAYsb5YjUsrnzpkexWB+WtBB

uWKoHCjocA1ebMcV2SxoZz7CzEUiku0LbBsfH0yrMCZqBBXtX30jNE7F6LPA5Zuw

a8XhX7w3iQgn9KAzolmLwwScBLwwynSoeHRNN5oii0a2YotkNvoSaBk3ydBWceQu

jJKRpKBA1jAD1dAIUnEsiJBQtHgj8dsEz+4rONwbR+mdr8WbPFozQlWiobZHra63

/q60b4cHAgo4psoVp6rq13iFtRbrSleHlZzYHhXQI7aYqjkHws28xndP9hcIKJSD

K8TzDI9d

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/

MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT

DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow

...

TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh

he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC

Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw

TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh

...

HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv

MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX

nLRbwHOoq7hHwg==

-----END CERTIFICATE-----

Trust Chain validation

When we navigate to a website, the browser will authenticate it during the beginning of the TLS handshake. TLS - Transport Layer Security (formerly called SSL- Secured Socket Layer ).

Authentication is done using the certificate. The browser will validate the period of the certificate, the signature, the domain, and a few more items.

Once the end-user certificate is validated, the browser will validate the same items on the intermediate certificate that signed that end-user certificate, he will also validate that this certificate did sign that end-user certificate. Then it continues to the top of the chain - the root certificate, which is self-signed, hence cannot be trusted, but since it is a global certificate authority, then the browser will trust it and the whole certificate chain is marked as trusted.

PKI - Public Key Infrastructure

A certificate is generated using a private key. It contains a public key in it, and it is cryptographically tight to that private key. Certificates will always be tight to a single private key and a private key will always be tight to a single certificate. This magical cryptographic infrastructure is based on a concept called PKI - Public Key Infrastructure.

Both the private key and the certificate contain the same public key and by using the private key and the public key we perform the TLS handshake.

PKI Encryption

The following flow shows the basics of PKI encryption.

Alice wants to send an encrypted message to Bob -

1. Bob sends Alice his public key

2. Alice encrypts her message using Bob’s public key and sends it to him over the internet.

3. Bob decrypts that message using his private key.

Now for two side communication, both need to exchange public keys. Also, in order to make sure they are talking to each other and not to someone else, they are using the public key infrastructure to authenticate using a digital signature.

This process has many flaws, hence in actual secured communication we use the TLS protocol, which is based on this process, but much more complex, and with additional security layers.

Server certificate VS Client certificate

A server certificate is served by the server, it has a Subject Alerternative Name that covers the domain of the website. It gives the client the ability to authenticate the server.

A client certificate is served by the client, it gives the server the ability to authenticate the clients. Client certificates do not have Subject Alternative Name.

When a server is configured to request a client certificate it means that only specific users with an appropriate client certificate will be able to complete a TLS handshake with the server, all other clients are forbidden. Most websites are open for all clients, hence not configured to work with client certificates.

In the next tutorial we will see how we can use OpenSSL in order to create certificates, private keys and more.