Ceci est une ancienne révision du document !
Table des matières
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.
Champs DNS
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
Usage de certbot
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».
–standalone. Si le port 80 est déjà utilisé par un autre serveur, la procédure sera différente.
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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Si les conditions sont respectées (résolution DNS correcte, port 80 accessible), le certificat doit être validé. Il y a plusieurs choses à éclaircir:
- Bien que les logs soient plutôt indigestes, ce n'est pas forcément inutile d'y aller faire un tour.
- 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.
- 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!
- 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. - 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:- 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.
- chain.pem décrit la suite de CA mise en œuvre.
- 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
Le certificat est bien issu de Let's Encrypt, il est valable 3 mois, nous retrouvons les informations permettant d'obtenir les listes de révocation.
Ce qui est remarquable, c'est:
- le choix de l'algorithme de courbe elliptique pour le chiffrement, actuellement considéré comme plus solide que RSA,
- les «alternatives names» qui permettent d'utiliser le même certificat pour plusieurs URI, conformément à la demande.
Et s'il y a déjà un serveur http ?
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.
Renouvellement du certificat
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