A bit of history and background information

When the first computer networks appeared, only local networking was available: the protocols and standards defining the internet were officialy set in 1983 but large computer networks already existed for research purposes such as MIT's ARPANET created in 1969.

Because "local" networks are usually of a small scale and set up by the entity that owns it, there is no need to identify the equipment through the network other than what they do or are (printer, server, storage, ...) even though some networks could span multiple campuses.

Internet being an extension of these "local" networks, they applied same basic principles including the lack of requirements in regards to secure data transfer. It doesn't mean that the technologies or tools to apply such security wasn't available, only that it was not mandatory.

But with the rapide growth of the internet in the late 90's and early 2000's, the lack of secure data transfer or ways to check data source & integrity became more and more apparent, especially for e-commerce or any online procedure dealing with personnal information.
In 2000, the HTTPS protocol was created but remained only partially used until 2007 when Google started requiring websites handling personnal data to implement it.

In short, if you want to have a website today, you have to use certificates so let's see how.

How does a certificate secure your website ?

For anyone having used SSH or SFTP, you will find the same basic principles in use:

  • when a user connects to a website, the client browser will initiate an identification process call "Hello client" to initiate the agreement on the encryption protocol to be used for future exchanges.

  • the browser will then check the exposed certificate's content to verify the accuracy of the information but also use it in the data encryption

  • the certificate is signed with the private key of the trusted Certificate Authority that generated it. That signature will be checked by the web browsers using the public keys of the major certificate authorities it has.

  • if the signature checks out, the system will verify the content of the certificate (domain name and ip address) and confirms with the Certificate Authority that the address listed in the certificate is the one to which it has an open connection.

  • depending on the exact protocol used, a symmetric encryption key will be generated either by the client (TLS 1.2) or the server (TLS 1.3) to encrypt the data between server and client.
    Since the server identity is verified the client can be sure, that this "key exchange" is done with the right server and not some man in the middle attacker.

Certificates (even unsigned) will prevent people from listening in on your traffic, since they have no way to gain access to the shared symmetric key used to encyrpt/decrypt the data.

Checking with a third party such as a Certificate Authority prevents man-in-the-middle attacks.

Public information contained in a certificate

Because this website is only a small side occupation with very little requirements, I've been using the free Let's Encrypt certificates.

Field Description Example
Common Name (CN) The domain name that the certificate was issued for nicksopenworld.com
Organization (O) The person/organization/device it was issued to <Not Part Of Certificate>
Organizational Unit (OU) The person/organization/device it was issued to <Not Part Of Certificate>
Common Name (CN) In this occurence, the system that the certificate was issued by R3
Organization (O) The Certificate Authority that generated it Let's Encrypt
Organizational Unit (OU) The Certificate Authority that generated it <Not Part Of Certificate>
Issued On Issue date of the certificate Tuesday, January 30, 2024 at 2:08:09 PM
Expires On Expiration date of the certificate Monday, April 29, 2024 at 3:08:08 PM
Certificate That Certificate Authority's digital signature 4b63c5e431ee61dd125a93601a5c19f66af68554cb39003d90912fb8efc0417e
Public Key The public key (the private key is kept secret) 63e668630ce5c92f4874b7f024977e0b01e0fd1ec90f894a7eb826a797c32fd5

But depending on the type of certificate and it's use, other information could be present such as the Location, State/Province, Email...

Field identifier Field name Example
CN CommonName www.example.com
C Country US
ST State Name San Francisco
L Location California
O Organization Security
OU OrganizationalUnit IT Department

So when a browser gets a certificate to verify, the data to be checked is taken from these fields as defined in the X.509 standard.

Because the variations are too many, here are a few examples:

The fields are shared standards and you can find their definitions in rfc4519 and rfc4514 among other files.

Private information used to generate a certificate

In the exposed fields, you can find the public key which implies that there is a matching private key with a password required to use it.

Basic certificate generation

Here is how a certificate is generated and the information needed:
openssl x509 -signkey domain-private.key -in domain.csr -req -days 365 -out domain.crt

As defined OpenSSL documentation:

  • in : input file, in this case a Certificate Signing Request
  • signkey : declares the certificate as being self-signed using the private key file declared
  • req : forces the uses of a Certificate Signing Request instead of a Certificate as input
  • days: duration validity for the generated certificate. Although it used to be up to 10 years in the early 2000's, it is now limited to 397 days for SSL/TLS certificates used for web-exposed services.
  • out : output file generated

Step by step creation of a certificate

  1. Generate a private Key
    Without password:

openssl genrsa -out nowprivate.key 4096

Password-protected:
openssl genrsa -des3 -out nowprivate.key 4096

A prompt will appear:
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

If values don't match, you'll be notified:
Verify failure
4037EB50657F0000:error:1400006B:UI routines:UI_process:processing error:../crypto/ui/ui_lib.c:544:while reading strings
4037EB50657F0000:error:0480006D:PEM routines:PEM_def_callback:problems getting password:../crypto/pem/pem_lib.c:62:
4037EB50657F0000:error:07880109:common libcrypto routines:do_ui_passphrase:interrupted or cancelled:../crypto/passphrase.c:184:
4037EB50657F0000:error:1C80009F:Provider routines:p8info_to_encp8:unable to get passphrase:../providers/implementations/encode_decode/encode_key2any.c:116:

  1. Create the Certificate Signing Request

openssl req -key nowprivate.key -new -out now.csr

If the private key is password protected, a prompt will ask for the password.

Enter pass phrase for nowprivate.key:

Then you will be asked to provide the information for the certificate:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ile de France
Locality Name (eg, city) []:Paris
Organization Name (eg, company) [Internet Widgits Pty Ltd]:NickOpenWorld
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:nicksopenworld.com
Email Address []:someemail@nicksopenworld.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

  1. Generating the Certificate

This is the command to generate a self-signed certificate:
openssl x509 -signkey nowprivate.key -in now.csr -req -days 28 -out nowcertificate.crt

Again, if the private key is password-protected a prompt will ask for the password.

Enter pass phrase for nowprivate.key:

You will then be provided with the details of the certificate:

Certificate request self-signature ok
subject=C = FR, ST = Ile de France, L = Paris, O = NickOpenWorld, OU = IT, CN = nicksopenworld.com, emailAddress = contact@nicksopenworld.com

At this point, the certificate is self-signed and not linked to any Certificate Authority.

  1. Getting a CA signed certificate

Third party validation by a Certificate Authority requires your certificate to be generated using the CA private key and certificate in combination to your Certificate Signing Request and additionnal information ( "domaininfo.ext" in our example below):
openssl x509 -req -CA CAcertificate.crt -CAkey CAcertificateprivatekey.key -in now.csr -out nowcertificate.crt -days 90 -CAcreateserial -extfile domaininfo.ext

If you want to set up your own CA:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = domain

If you don't have a domain, you can set it as localhost:

DNS.1 = localhost

Generate a certificate using a proper CA - Let's Encrypt

In Linux Ubuntu, install the "certbot" package :
sudo apt install -y certbot

You can then generate the certificate as a standalone file:
sudo certbot certonly --cert-name nicksopenworld.com -d nicksopenworld.com

It will call Let's Encrypt certification servers containing the required CA private key and certificate.
A prompt will ask for complementary information:

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): someemail@nicksopenworld.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: n
Account registered.
Requesting a certificate for nicksopenworld.com

Check your local firewall or network configuration if you are getting the error:

Could not bind TCP port 80 because it is already in use by another process on
this system (such as a web server). Please stop the program in question and then
try again.

Once the certificate generation has successfully completed, you will find that files have been generated in the folder "/etc/letsencrypt/live/[DOMAIN_NAME]/".

File Description
cert.pem Your end-entity certificate's public key
chain.pem intermediate certificate which was signed by a trusted root as detailed in Let's Encrypt Chain of Trust
fullchain.pem cert.pem + chain.pem
privkey.pem private key genreated and used for that certificate generation

This will enable you to deploy certificates as you need without having to pay for a certificate.

Also, for the most common web server applications, there is a built-in Certbot module that set's up the generated certificates using the proper formats and even going so far as to reboot the service meaning that it can be fully automated.

Other CA options exist, are they more secure than Let’s Encrypt ?

In short: No!

What paid SSL providers offer in regards to basic certification services works using the same protocols and security standards as those used by Let's Encrypt.

The difference is mainly in the service around it:

  • Let's Encrypt certificates have a maximum 90 day validity period whereas other providers can go up to 397 days (as per the latest standards)
  • Ease of use: paying services usually means having a user interface from which you can select the certificate formats and contents you want to retrieve as opposed to a fully command-line-based interface that might also need specific packages or arguments to get the same result
  • Renewal policies: because the service is free, Let's Encrypt limits the number of authorised renewals over periods of time.
  • Support: if you have questions about how to use certificates, Let's Encrypt has forums but a paying service would have a way to contact technicians

Conclusions

Certificates have been around long enough that there is ample documentation whatever solution you choose.

And your technical requirements should define what to use:

  • if you are still maintaining systems where certificates are manually uploaded and renewed, you might want to have a longer validity period
  • if you are using a modern mainframe with built-in automation, Let's Encrypt might be the key
  • you you are using an older system, no longer want to pay for longer lasting certificates but can't be bothered by automation, then solutions such as Traefik using Let's Encrypt could help

Whatever the case, the same mecanics described in this article will be used.

And if you want to go further into the technical details, I would recommend:

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x