---
pubDate = 2025-01-25T16:09:04
tags = ['https', 'web', 'nginx', 'linux', 'cryptography']
lang = "en"
type = "note"

[author]
name = "ache"
email = "ache@ache.one"

[[alt_lang]]
lang = "fr"
url = "/notes/créer-un-certificat-auto-signé-depuis-un-CA-auto-signé"
---

# Obtaining a self-signed SSL certificate from our own Certificate Authority

![Illustration of a self-signed certificate](res/certificat-signed-alt.svg)
In this blog post, we will create a self-signed TLS certificate, install it on an nginx server and on client systems.

## Objectives of the TLS Protocol

:::attention
Generally, you do not want a self-signed certificate.
If you want to obtain a valid certificate on the internet, then you need it to be verified by a trusted Certificate Authority (CA).
In this case, [Let's Encrypt](https://letsencrypt.org/fr/) can certainly provide the certificate you need.
:::

TLS authentication is used to **verify that** the server you want to connect to (by its **domain name**) **is indeed the server** that has authority over that domain name.
This may seem abstract, but there are several reasons why a domain name may not redirect to the correct server.

- A lying DNS
- A compromised router redirects you to the wrong server
- A configuration error (on either the client or the server side)
- ...

Subsequently, TLS will handle encryption that ensures confidentiality and integrity.

TLS is a protocol used as an overlay on many other protocols (FTP, IMAP, SMTP, ..., and even DNS!) to add security to them.

## Certificate Chain (or Chain of Trust)

We do not have a list of certificates issued on our computers. It would be too complicated to manage, heavy, difficult to update and ultimately unreliable.[^ct-logs]

[^ct-logs]:
    The role of _Certificate Transparency (CT) logs_ is to ensure that any suspicious behavior (at the level of certificate issuance) can be detected.
    For more information, see <https://certificate.transparency.dev/>.

<img src="res/chain_of_trust.png" class="big" alt="Schema of the Certificate Chain">

On the contrary, we have only a relatively small list of certificates of trust on our computers (149 in my case).
These are the root certificates.
These certificates will delegate their role of identity verifier to others.
These intermediate authorities then have the role of ensuring that the request for certification comes from the correct server and issuing a signed certificate (and of short duration, i.e., several days at most, up to a few months).

In our case, we will pass the intermediate certificate step as we will never delegate our authority.

:::info
The certificates installed on your computer are selected by your operating system (for example, [that of Windows](https://ccadb.my.salesforce-sites.com/microsoft/IncludedCACertificateReportForMSFT)).
Often, this delegates your trust to a certificate selection organization such as [Mozilla](https://wiki.mozilla.org/CA/Included_Certificates).
:::

### Under Arch Linux

Arch Linux uses [p11-kit](https://github.com/p11-glue/p11-kit) to manage certificates.

Just like on Ubuntu and Debian systems, the list of certificates is available in the PEM format in the `/etc/ssl/certs` directory.

OpenSSL is the reference tool for TLS. You can use it to display a certificate as follows:

```shell
$ openssl x509 -noout -text -in $certificat
```

In the case of a website, you can query the certificate of a website with the following command:
`

```shell
$ openssl s_client -connect ache.one:443 -verify_return_error </dev/null >/dev/null
Connecting to 2001:41d0:601:1100::11dc
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R10
verify return:1
depth=0 CN=ache.one
verify return:1
DONE
```

One can add :

- `-showcerts` to print the server certificat
- `-servername` to set a SNI field
- `-starttls` with `smtp`, `ldap`, `pop3`, `xmpp`... to verify that a TLS setup is compatible with StartTLS.
-
- We can also extract the certificate into a file as follows:

  ```shell
  $ openssl s_client -connect ache.one:443 -servername ache.one < /dev/null | \
            openssl x509 -outform PEM > ache_one.cert
  ```

- To verify dates of a certificate :

  ```shell
  $ openssl x509 -in ache_one.cert -noout -dates # Pour un certificat que l'on possède localement
  notBefore=Wen 16 15:27:33 2025 GMT
  notAfter=Wen 30 15:27:33 2025 GMT
  $ openssl s_client -servername ache.one -connect ache.one:443 2>/dev/null </dev/null | \
            openssl x509 -noout -dates
  ```

## Créer le certificat racine

Firstly, let's create a private key.
We will use RSA with a 3072-bit key.

```shell
$ openssl genrsa -out root_ca.key 3072
```

To use elliptic curves, we will rather use `openssl ecparam -genkey` and select a curve from the available options `openssl ecparam -genkey -list_curves` (make sure to get informed about the support of the chosen curve).  
Then, we create the certificate and sign it.

```shell
$ openssl req -x509 -key local_ca.key -nodes -utf8 -days 3650 -out local_ca.cert -config local_ca.conf
```

With this configuration file :

```toml
[ req ]
default_bits        = 3072
distinguished_name  = x509_distinguished_name
x509_extensions = x509_ext
prompt = no

[ x509_distinguished_name ]
countryName		= "FX"
stateOrProvinceName	= Pays des bisounours
organizationName	= ache
organizationalUnitName	= ache
commonName = ache.local
emailAddress = ache@ache.one

[ x509_ext ]
basicConstraints=critical,CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
extendedKeyUsage=critical,serverAuth
subjectAltName=email:ache@ache.one,DNS:local,DNS:ache.local
# keyUsage = critical, digitalSignature, cRLSign, keyCertSign
keyUsage = critical, digitalSignature, keyEncipherment, keyCertSign
```

Here, it's important to use `x509_extensions` instead of `req_extensions`, and the line `basicConstraints` specifies `CA:TRUE`.

:::note
It is possible to perform these two steps in one single command:

```shell
$ openssl req -x509 \
            -sha256 -days 3650 \
            -nodes \
            -newkey rsa:3072 \
            -subj "/CN=ache Root CA/C=FR/L=La grande ville" \
            -keyout root_ca.key -out root_ca.cert
```

:::

### Add the root certificate to the list of trusted certificates

On the client side, we can already install the self-signed CA for the clients.
For Arch Linux clients, this is done with the command `trust`.

```shell
# trust anchor --store root_ca.cert
```

One can verify if it is indeed on the list by checking its name.

```shell
$ trust list | rg -C 2 "ache"
pkcs11:id=%F4%30%84%A6%0F%AD%AF%BB%6C%3A%2D%C6%1A%66%84%48%73%4E%CB%E7;type=cert
    type: certificate
    label: ache Root CA
    trust: anchor
    category: authority
```

:::warn
We take this opportunity to make sure that the certificate is an authority certificate (category _authority_) and indeed that it is a certificate (type _certificate_).
:::

It will then be installed in the directory `/etc/ca-certificates/trust-source/`.
To remove the certificate from the trusted certificates, we use the file generated in this directory.

```shell
# trust anchor --remove /etc/ca-certificates/trust-source/ache.dns.p11-kit
```

## Creation of the DNS Certificate

Same as before, we start by creating a private key.

### The Private Key

```shell
$ openssl genrsa -out website.key 3072
```

Then, we create a **signature request**.
This allows us to configure the signature by the certification authority.

### The Signature Request

Normally, in the usual process, the Intermediate Certification Authority receives a signature request and initiates then the process of verifying the identity of the server that is requesting the signature.

We can do this easily with OpenSSL:

```shell
$ openssl req -new -key website.key -out website.csr -utf8 -nameopt multiline,utf
```

:::info
Here, I have added the parameters `-utf8 -nameopt multiline,utf8` so as to accept non-ASCII characters in the certification information (Company name, region ...).
:::

OpenSSL will then ask for the certification information interactively.
This can be avoided either by filling in the data directly on the command line.

```shell
$ openssl req -new -out website.csr -sha256 -days 3650 -nodes -subj "/C=FR/ST=Centre/L=La grande Ville/O=NomDeLEntreprise/OU=/CN=CommonNameOrHostname"
```

Or by using a configuration file.
This is what I chose to do in order to facilitate the re-creation of the certificate.

```shell
$ openssl req -new -key website.key -out website.csr -utf8 -nameopt multiline,utf8 -config website.conf
```

The configuration file looks like this:

```toml
[ req ]
prompt = no
default_bits = 3072
default_md = sha256
distinguished_name = server_distinguished_name
req_extensions = v3_ext

[ server_distinguished_name ]
commonName = ache
countryName = FR
stateOrProvinceName = XXX
emailAddress = ache@ache.one
organizationName = ache local CA organization

[ v3_ext ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.0 = website.ache.one
DNS.1 = website_alt.ache.one
```

## Creating the final certificate

There is only one step left: creating the final certificate.
The following are required for this purpose:

- Root certificate private key
- Root certificate
- The final certificate private key
- The Certificate signing request (CSR)

```shell
$ openssl x509 -req -CA ../root_ca/root_ca.cert -CAkey ../root_ca/root_ca.key -in website.csr -out website.cert -days 10 -CAcreateserial -extensions v3_ext -extfile website.conf -sha256
```

## Configuring the certificate in nginx

There is nothing magical about it.
We add `ssl` to the `listen` and configure TLS.
To do this, we need to indicate where the encryption key is located as well as the certificate.

```text
  listen [::]:443 ssl;
  listen 443 ssl;
  http2 on; # Not related to TLS

  ssl_certificate /srv/www/website.cert; # managed by myself !
  ssl_certificate_key /srv/website/cert/website.key;
  ssl_stapling off; # Since it's a self-signed certificate. No need for OCSP stapling.
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
```

It can be noticed that it is possible to pass the certificate chain also by concatenating the final certificate (first) with the root certificate.
I do not know if this has a real advantage, but it is a common practice.

## Certificate Update

It is recommended to set up an automatic method for updating the certificate.
I recommend a systemd timer that will check the validity of the certificate and renew it at regular intervals.

`check-certificates.timer` :

```toml
# This timer unit is for refreshing local certificates everyday

[Unit]
Description=Refresh self-signed certificates regularly
Requires=check-certificates.service


[Timer]
Unit=check-certificates.service
OnUnitActiveSec=86400

[Install]
WantedBy=timers.target
```

And `check-certificates.service`

```toml
# This service unit is for refreshing local certificates if needed

[Unit]
Description=Refresh local certificates if needed
Wants=check-certificates.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/check-certificates.sh

[Install]
WantedBy=multi-user.target
```

I thus created a Bash script to automate the verification of certificates and the updating of Nginx configuration files.

:::details

Content of the file `check-certificates.sh`

::::summary

```bash
#!/bin/env bash

# This script checks the validity of the certificates in the directory
# ${CERTIFICATES_DIR} and renews them if necessary.
#
# It uses the local CA certificate and key to check the validity of the
# certificates in the directory ${CERTIFICATES_DIR}.
#
# The script is intended to be run from a systemd timer every day.


# TODO: Configure the following variables from cli arguments
# TODO: Rewrite this shit in Python
CERTIFICATES_DIR="/home/works/certs/"
LOCAL_CA_CERT="${CERTIFICATES_DIR}/local_ca.cert"
LOCAL_CA_KEY=$(echo "${LOCAL_CA_CERT}" | sed 's/.cert$/.key/')

HAS_RENEW_CERT=""
if [ ! -r "$LOCAL_CA_CERT" ]; then
  echo "☠️ Please re-check that local CA cert \"$LOCAL_CA_CERT\" exists"
  exit
fi
if [ ! -r "$LOCAL_CA_KEY" ]; then
  echo "☠️ Please re-check that local CA key \"$LOCAL_CA_KEY\" exists"
  exit
fi

date
echo -e "Checking certificate validity (NotAfter field)\n"

pushd ${CERTIFICATES_DIR} >/dev/null 2>/dev/null
for cert in $(find -name "*.cert"); do
  if openssl x509 -checkend 345600 -noout -in ${cert} > /dev/null; then
    echo -e "✔️ $(basename ${cert}) will expire in more than 4 days"
  else
    echo -e "❌ $(basename ${cert}) will expire soon !"
    if [ $(basename "$cert") = $(basename "$LOCAL_CA_CERT") ]; then
      echo -e "\t⛔ I don't renew local CA certificate"
      continue
    fi

    NEW_CSR=$(echo ${cert} | sed 's/.cert/.csr/')
    CERT_KEY=$(echo ${cert} | sed 's/.cert/.key/')
    CERT_CONFIG=$(echo ${cert} | sed 's/.cert/.conf/')

    echo "Renewing ${cert}"
    echo "Creating new CSR ($NEW_CSR)"
    echo ${cert}
    echo ${CERT_KEY}
    echo ${CERT_CONFIG}

    # Sign the new signing request
    if openssl req -new -key "${CERT_KEY}" -out "${NEW_CSR}" -config "${CERT_CONFIG}"; then
      echo "👍 CSR created"
    else
      echo "❌ Failled to create signing request!"
      continue
    fi

    echo "Renewing certificate"
    openssl x509 -req -CA "${LOCAL_CA_CERT}" -CAkey "${LOCAL_CA_KEY}" -in "${NEW_CSR}" -out "${cert}" -days 10 -CAcreateserial -extensions v3_ext -extfile "${CERT_CONFIG}" -sha256
    if [ $? -eq 0 ]; then
      HAS_RENEW_CERT="yes"
      echo "✔️ Certificate renew"
    else
      echo "❌ Failled to renew certificate!"
    fi
  fi
done

echo -e "\nNo more certificate to check"
if [ -n "$HAS_RENEW_CERT" ]; then
  echo "🔃 Reload nginx configuration (and update certificates)"
  nginx -s reload
fi

popd >/dev/null 2>/dev/null
```

::::