Appel à Let's encrypt

Les distributions GNU/Linux proposent l'outil certbot qui permet facilement de réaliser un CSR et de demander sa signature à «Let's Encrypt». Il y a bien évidemment quelques conditions à remplir:

• disposer d'un nom de domaine officiel,
• disposer d'un serveur accessible depuis l'internet, référencé par le serveur DNS de la zone.

Pour les besoins de la démonstration, un sous-domaine «home.nain-t.net» ainsi qu'un hôte «mail.home.nain-t.net». Nous allons obtenir de la part de Let's encrypt, un certificat X509 qui pourra être utilisé pour exploiter TLS aussi bien avec un serveur web que smtp.

Pour les besoins de certbot, des adresses IPv6 suffisent dans la zone «home.nain-t.net», mais avec des adresses IPv4 ça fonctionnerait bien sûr aussi.

home.nain-t.net.      	AAAA 	2a01:e0a:875:b1d0::10
mail.home.nain-t.net.  	AAAA 	2a01:e0a:875:b1d0::10

Plusieurs possibilités s'offrent pour effectuer une demande de certificat à Let's Encrypt et par la suite à effectuer son renouvellement. L'outil «certbot» est certainement le plus souple et le plus simple d'emploi.

Il est nécessaire que la CA puisse accéder à un serveur http implanté sur le demandeur. Si ce n'est pas le cas, certbot peut créer un mini serveur http temporaire, ce qui sera le cas ici.

Tous les paramètres utilisables avec la commande «certbot» sont détaillés dans le manuel et sur le site officiel. Nous exploitons ici une extension possible des certificats X509, qui permet d'utiliser le même certificat pour «home.nain-t.net» et «mail.home.nain-t.net».

certbot certonly --standalone -d home.nain-t.net. -d mail.home.nain-t.net.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for home.nain-t.net and mail.home.nain-t.net

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/home.nain-t.net/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/home.nain-t.net/privkey.pem
This certificate expires on 2025-07-28.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1. Bien que les logs soient plutôt indigestes, ce n'est pas forcément inutile d'y aller faire un tour.
2. la clé comme le certificat se trouvent dans des fichiers de suffixe «pem» (Privacy Enhancement for internet electronic Mail). Format défini par le RFC 1422. Sa particularité étant de pouvoir empaqueter aussi bien une clé publique qu'une clé privée ou même les deux ensemble. Généralement, il vaut mieux stocker la clé privée à part.
3. Let's Encrypt fournit des certificats d'une durée de validité de 3 mois. Il est donc nécessaire de penser à les renouveler avant expiration!
4. certbot crée une tâche de fond qui se charge de réaliser automatiquement l'opération dans une «crontab» située dans /etc/cron.d/ chez Debian.
5. Si nous regardons de près le contenu de /etc/letsencrypt/live/home.nain-t.net/ nous trouvons bien plus de 2 fichiers au format «pem». En réalité nous avons:
   1. cert.pem est le certificat lui-même. Mais contrairement à notre essai de CA interne, Let's Encrypt n'est pas une CA «racine» Elle est elle-même certifiée par d'autres CA.
   2. chain.pem décrit la suite de CA mise en œuvre.
   3. fullchain.pem contient toutes les informations. Une concaténation des deux informations précédentes. C'est ce certificat qu'il convient d'exhiber aux clients.

Si nous regardons son contenu:

openssl x509 -in fullchain.pem -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            06:87:a5:dd:2b:61:33:af:1b:e8:0c:c6:1f:86:ec:d0:c1:b8
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=Let's Encrypt, CN=E5
        Validity
            Not Before: Apr 29 06:30:54 2025 GMT
            Not After : Jul 28 06:30:53 2025 GMT
        Subject: CN=home.nain-t.net
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:c0:c7:1b:d7:0c:54:cb:69:9c:63:58:dd:c1:f1:
                    64:4c:6c:f7:1d:0f:df:36:fb:68:60:83:f2:61:87:
                    16:13:8f:bd:0a:6a:1d:b2:73:af:99:69:18:f1:33:
                    0d:a3:0b:0d:49:a5:3f:e2:2c:a0:18:99:15:24:ef:
                    bb:be:80:47:92
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                52:E7:A7:68:16:22:64:6B:AD:4D:55:E4:E0:9F:C5:88:5A:C0:F3:4B
            X509v3 Authority Key Identifier: 
                9F:2B:5F:CF:3C:21:4F:9D:04:B7:ED:2B:2C:C4:C6:70:8B:D2:D7:0D
            Authority Information Access: 
                OCSP - URI:http://e5.o.lencr.org
                CA Issuers - URI:http://e5.i.lencr.org/
            X509v3 Subject Alternative Name: 
                DNS:home.nain-t.net, DNS:mail.home.nain-t.net
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://e5.c.lencr.org/57.crl

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : ED:3C:4B:D6:E8:06:C2:A4:A2:00:57:DB:CB:24:E2:38:
                                01:DF:51:2F:ED:C4:86:C5:70:0F:20:DD:B7:3E:3F:E0
                    Timestamp : Apr 29 07:29:24.364 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:73:4E:F3:F2:31:E8:D7:72:3E:99:EE:34:
                                0E:6C:62:D4:5C:16:0B:DB:01:A2:37:C0:9B:F1:8E:BE:
                                9D:B6:26:09:02:20:3A:E5:BC:CF:34:2D:48:2A:F6:C0:
                                04:D6:05:97:0D:41:09:BB:D4:68:B9:99:32:1A:66:D6:
                                17:69:9B:47:ED:F8
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : DD:DC:CA:34:95:D7:E1:16:05:E7:95:32:FA:C7:9F:F8:
                                3D:1C:50:DF:DB:00:3A:14:12:76:0A:2C:AC:BB:C8:2A
                    Timestamp : Apr 29 07:29:24.414 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:4A:B7:A7:63:49:0C:A9:31:5E:79:07:8B:
                                5F:B0:01:D7:08:01:3D:AD:CF:0B:83:E8:83:D6:C2:94:
                                21:7F:FC:F5:02:21:00:CC:24:BA:7A:0E:5C:37:AB:F0:
                                9F:24:73:0C:AB:0F:A2:24:71:52:17:26:37:01:7C:EB:
                                FB:B8:AB:3C:08:FB:4F
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:65:02:30:4c:d3:83:6c:7a:5f:36:67:4b:ff:b6:99:56:58:
        e3:c4:3c:28:bd:f0:06:a8:1c:03:ef:a2:bf:27:70:0e:0d:ac:
        eb:82:45:78:1c:64:fa:f7:0f:3b:db:ce:38:da:a3:29:02:31:
        00:e5:39:c1:df:3a:b2:6f:96:68:51:fb:49:bc:6a:13:b7:bc:
        a4:2b:c3:30:e7:41:e8:af:a0:4e:fa:57:43:2c:cc:e2:f6:61:
        fa:5c:49:7e:45:0e:bf:e6:a0:cd:72:a6:91

Ce qui est remarquable, c'est:

1. le choix de l'algorithme de courbe elliptique pour le chiffrement, actuellement considéré comme plus solide que RSA,
2. les «alternatives names» qui permettent d'utiliser le même certificat pour plusieurs URI, conformément à la demande.

Dans ce cas, certbot propose bien d'autres solutions. Trop nombreuses pour être traitées ici. La documentation officielle détaille toutes les solutions possibles.

Le problème est ici d'autant plus important que la durée de validité du certificat est de seulement trois mois. La norme prévoit de pouvoir renouveler un certificat existant, en en faisant la demande à la PKI.

Debian 12 et suivantes, lors de l'installation de certbot, a mis en place une tâche «cron» que l'on peut retrouver dans /etc/cron.d/certbot. Elle a également installé les fichiers certbot.timer et certbot.service dans /usr/lib/systemd/system

systemctl status certbot.timer

● certbot.timer - Run certbot twice daily
     Loaded: loaded (/usr/lib/systemd/system/certbot.timer; enabled; preset: enabled)
     Active: active (waiting) since Sun 2025-06-08 17:48:17 CEST; 1h 14min ago
 Invocation: 49171d78e066413785a2920c493b3830
    Trigger: Mon 2025-06-09 01:14:30 CEST; 6h left
   Triggers: ● certbot.service

les «hooks» permettent de faire appel à des scripts personnels durant certaines étapes du processus de renouvellement de certificats. Sur Debian, ces scrips peuvent être placés dans /etc/letsencrypt/renewal-hooksà trois étapes particulières:

1. avant le début du processus dans le sous-répertoire pre,
2. lors du déploiement du renouvellement réussi dans le sous-répertoire deploy,
3. à la fin du processus dans le sous-répertoire post.