Motivation

At work I'm using, and have used, DigiCert issued certificates through Geant TCS (formerly known as Terena) which is common to our sector. This approach require a lot of manual work, both when creating the csr, requesting the cert and installing the cert on the server. This does not scale along with the idea of automatically created servers and services, so we have to find a way to programmatically get our tls certificates.

What I want

A automated way to get the webtraffic encrypted is the main purpose of this exercise. The end result should not be less secure than what I have today.

Let’s Encrypt

One of the main historically drawbacks with Let’s Encrypt has been related to the fact that it was not trusted as a CA. This was solved by make sure all certs issued by Let’s Encrypt from 2015 and to this day was signed by Let’s Encrypt AND IdentTrust, so called cross-signing.

On july 2018 the Let’s Encrypt root was trusted by Microsoft products, and through the summer of 2018 all major vendors included Let’s Encrypt as a trusted root. Reference: https://letsencrypt.org/2018/08/06/trusted-by-all-major-root-programs.html

With Let’s Encrypt now trusted by the main rootstores I will give it a fair chance and see how it compares for my usecase.

Comparison of Let’s Encrypt and Terena certificates

The first part is to poke a bit around and look at the various attributes of the different certs.

$ echo | openssl s_client -showcerts -servername visualisere.no -connect visualisere.no:443 2>/dev/null | openssl x509 -inform pem -noout -text
$ openssl s_client -showcerts -connect visualisere.no:443
$ nmap -p 443 --script ssl-cert visualisere.no

The last one requires nmap installed to work.

% nmap -p 443 --script ssl-cert visualisere.no
...
PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=www.visualisere.no
| Subject Alternative Name: redacted
| Issuer: commonName=Let's Encrypt Authority X3/organizationName=Let's Encrypt/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-11-29T20:42:43
| Not valid after:  2020-02-27T20:42:43
| MD5:   34f6 050c 52f0 2a66 1491 5db3 6086 0055
|_SHA-1: 324b 5f21 0913 1e51 60e9 507e 564f 2db5 2c39 3d58

% nmap -p 443 --script ssl-cert uib.no
...
PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=p1masterlb.uib.no/organizationName=Universitetet i Bergen/countryName=NO
| Subject Alternative Name: redacted
| Issuer: commonName=TERENA SSL CA 3/organizationName=TERENA/stateOrProvinceName=Noord-Holland/countryName=NL
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-11-22T00:00:00
| Not valid after:  2021-12-01T12:00:00
| MD5:   9595 257d 3d71 32d0 c7b1 d758 ca4d 0bec
|_SHA-1: d0a9 4ee0 9296 9f86 8434 b6f5 b303 3204 d4a1 ca93

A quick glance yields same key-type, key-length and signature algorithm. The main difference is the difference between valid before and valid after. Let’s Encrypt certificates does not last longer than 90 days, but DigiCert certificates can be valid for years (in this example 1 year). The DigiCert certificates is also a so called organization validated certificate, which means that there has been some sort of validation of the organization that is stated in the certificate. Let’s Encrypt certificates is domain validated and have no concept of an organization, just that the receiver of the certificate controls the domain which the certificate is issued for.

Read more about DV certs: Domain Validated certificates

Read more about OV certs: Organization Validated certificates

We start to see some differences between the Let’s Encrypt and DigiCert alternatives, but let's continue to explore.

Compability (or lack of it) of Let’s Encrypt and Terena certificates

DigiCert root compability is close to everywhere, but Let’s Encrypt, as the new player, is not supported on some system. For Let’s Encrypt certificates the system need IdenTrust’s DST Root X3 in its root store AND support SHA-2. Nintendo 3DS, PS3 and PS4 game consoles is some of the system that does not support Let’s Encrypt certificates.

Let’s Encrypt supported and unsupported list

DigiCert supported list

Since this exercise is for a particular usecase, and I see all my systems on the supported list for both Let’s Encrypt and DigiCert I will continue to explore.

Revocation of certificates

As an attempt to solve the issue with bad certificates (mis-issued, lost-keys or otherwise no-longer-valid certificates) Google has launched the Certificate Transparency project (CT).

The project focus on three main goals:

• Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
• Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
• Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.

Reference: What is Certificate Transparency

The project creates an open framework consisting of:

• Certificate Logs
• Monitors
• Auditors

For this excersise, the Certificate Logs are the main focus, and both Let’s Encrypt and DigiCert submit certificates to a log.

A list of logs trusted by Chrome can be obtained in json format from: https://www.gstatic.com/ct/log_list/v2/log_list.json

You can also use the service https://crt.sh/ to search validity of a certificate.

A list of Certificate Logs that crt.sh monitors can be found here: https://crt.sh/monitored-logs

Both Let’s Encrypt and DigiCert submit certifcates to recognized and accepted CT logs.

Ease of use

The last parameter I want to compare is the ease of use. How hard is it for me as a developer to secure the traffic to/from my server with a certificate?

Let’s Encrypt has a commandline-tool called certbot which is the recommended interface to Let’s Encrypt certificates.

According to certbot's own documentation you can use this procedure to retrieve and install a certificate on your Centos8/RHEL8 Apache webserver:

$ wget https://dl.eff.org/certbot-auto
$ sudo mv certbot-auto /usr/local/bin/certbot-auto
$ sudo chown root /usr/local/bin/certbot-auto
$ sudo chmod 0755 /usr/local/bin/certbot-auto
$ sudo /usr/local/bin/certbot-auto --apache
$ echo "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot-auto renew" | sudo tee -a /etc/crontab > /dev/null

DigiCert has a webgui that you fill your information in and you get an openssl command to generate your csr.

$ openssl req -new -newkey rsa:2048 -nodes -out visualisere_no.csr -keyout visualisere_no.key -subj "/C=NO/ST=/L=/O=Name Surname/CN=visualisere.no"

The rest of the process, retrieving and installing your DigiCert certificate on your apache installation consist of 4 steps:

• Copying your certs to the server
• Locating your Apache config
• Manually editing the config
• Restarting the Apache service.

In my opinion Let’s Encrypt wins the ease of use comparison, it can easily be automated and are already setup for automatical renewal of the certificate when needed.

Summary

The difference between Let’s Encrypt and DigiCert for my usecase is not that big. My main goal is to encrypt traffic to/from my server, so I can accept that Let’s Encrypt is not doing organisazion validation. The ease of use, and ease of automation that Let’s Encrypt brings makes it a clear winner in this usecase. For other usecases, DigiCert might be the preferred option.