Let's Encrypt et ACME

Let’s Encrypt est une CA publique gratuite, automatisée et ouverte, lancée en 2016 par l’ISRG. Elle a démocratisé HTTPS en permettant à n’importe quel site d’obtenir un certificat DV en quelques secondes.

ACME (Automatic Certificate Management Environment — RFC 8555) est le protocole standard qu’elle a créé pour automatiser l’émission et le renouvellement des certificats.

Pourquoi Let’s Encrypt a changé le Web

Avant (2015) :
  - Certificats payants (50€ à 500€/an)
  - Processus manuel (CSR → email → validation → import)
  - Durée 1-2 ans → renouvellement oublié → site en panne
  - HTTPS = luxe pour les petits sites

Après (Let's Encrypt) :
  - Gratuit
  - Automatisé (certbot renouvelle tout seul)
  - 90 jours → renouvellement fréquent = sécurité accrue
  - HTTPS = standard pour tout le monde

En 2026, Let’s Encrypt protège plus de 300 millions de sites.

Le protocole ACME

ACME fonctionne en deux phases : prouver le contrôle du domaine puis émettre le certificat.

Client ACME (certbot)                    CA Let's Encrypt
      │                                        │
      │── 1. Créer un compte ACME ────────────►│
      │◄── compte + nonce (anti-replay) ───────│
      │                                        │
      │── 2. Demander un certificat pour ──────►│
      │       example.com                      │
      │◄── challenges à relever ───────────────│
      │       [HTTP-01 ou DNS-01 ou TLS-ALPN-01]
      │                                        │
      │── 3. Relever le challenge ─────────────►│
      │── 4. Notifier "challenge prêt" ────────►│
      │◄── CA vérifie ────────────────────────│
      │                                        │
      │── 5. Envoyer le CSR ───────────────────►│
      │◄── Certificat signé ───────────────────│
      │                                        │
      │── 6. Renouveler avant 60j ─────────────►│ (même processus)

Les 3 types de challenges

HTTP-01 — le plus courant

Le client crée un fichier sur le serveur web, la CA le vérifie via HTTP.

Client crée :
  http://example.com/.well-known/acme-challenge/TOKEN
  Contenu : TOKEN.THUMBPRINT_CLÉ_COMPTE

CA Let's Encrypt accède à cette URL → si la réponse correspond → domaine validé ✅

Limites :
  ❌ Ne fonctionne pas derrière un firewall fermé au port 80
  ❌ Ne supporte pas les wildcards (*.example.com)
  ❌ Nécessite un serveur web opérationnel

# Certbot avec HTTP-01 (mode standalone — ouvre un serveur web temporaire)
certbot certonly --standalone -d example.com -d www.example.com
 
# Certbot avec HTTP-01 (mode webroot — utilise le serveur web existant)
certbot certonly --webroot -w /var/www/html -d example.com

DNS-01 — wildcards et flexibilité

Le client crée un enregistrement TXT dans le DNS, la CA le vérifie.

Client crée :
  _acme-challenge.example.com  TXT  "TOKEN_BASE64URL"

CA Let's Encrypt résout _acme-challenge.example.com → si TXT correspond → validé ✅

Avantages :
  ✅ Fonctionne pour les wildcards : *.example.com
  ✅ Fonctionne sans serveur web (serveurs internes)
  ✅ Fonctionne derrière un firewall
  ✅ Peut être automatisé via l'API DNS du registrar

Limites :
  ⚠️ Nécessite l'accès à l'API DNS du registrar
  ⚠️ Propagation DNS peut prendre quelques minutes

# Certbot avec DNS-01 (plugin OVH)
certbot certonly --dns-ovh \
  --dns-ovh-credentials ~/.secrets/certbot/ovh.ini \
  -d "*.example.com" -d example.com
 
# Certbot avec DNS-01 (plugin Route53)
certbot certonly --dns-route53 \
  -d "*.example.com" -d example.com

TLS-ALPN-01 — validation via TLS

Le client configure un certificat auto-signé spécial sur le port 443, la CA s’y connecte.

Utile pour :
  ✅ Environnements où seul le port 443 est accessible
  ✅ Automatisation dans les proxies TLS (HAProxy, Traefik)
  ❌ Plus complexe à implémenter (peu de clients le supportent)

Certbot — le client ACME de référence

# Installation (Debian/Ubuntu)
apt install certbot python3-certbot-nginx
 
# Obtenir un certificat avec configuration nginx automatique
certbot --nginx -d example.com -d www.example.com
 
# Obtenir un certificat sans modifier la config (standalone)
certbot certonly --standalone -d example.com
 
# Tester le renouvellement (sans l'effectuer)
certbot renew --dry-run
 
# Renouveler tous les certificats
certbot renew
 
# Forcer le renouvellement d'un certificat spécifique
certbot renew --cert-name example.com --force-renewal
 
# Voir les certificats gérés
certbot certificates
 
# Révoquer un certificat
certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

Fichiers générés par certbot :
/etc/letsencrypt/live/example.com/
  ├── cert.pem        ← certificat uniquement
  ├── chain.pem       ← chaîne CA (intermédiaire)
  ├── fullchain.pem   ← cert + chaîne (à utiliser avec nginx/apache)
  └── privkey.pem     ← clé privée

# Configuration nginx recommandée
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Renouvellement automatique

# Certbot installe automatiquement un timer systemd ou cron
systemctl list-timers | grep certbot
 
# Le timer tourne deux fois par jour et renouvelle les certs < 30j avant expiration
# Vérifier le service de renouvellement
systemctl status certbot.timer

Let’s Encrypt dans Kubernetes avec cert-manager

cert-manager est le standard Kubernetes pour gérer les certificats via ACME.

# ClusterIssuer — Let's Encrypt Production
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@monentreprise.fr
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      # HTTP-01 via Ingress
      - http01:
          ingress:
            class: nginx
      # DNS-01 via Route53 (pour wildcards)
      - dns01:
          route53:
            region: eu-west-1
            accessKeyID: AKIAIOSFODNN7EXAMPLE
            secretAccessKeySecretRef:
              name: route53-credentials
              key: secret-access-key
        selector:
          dnsZones:
            - "monentreprise.fr"

# Certificate — demander un certificat wildcard
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-cert
  namespace: production
spec:
  secretName: wildcard-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - "monentreprise.fr"
    - "*.monentreprise.fr"
  # cert-manager renouvelle automatiquement 30j avant expiration

# Ingress — utiliser le cert via annotation
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
    - hosts:
        - api.monentreprise.fr
      secretName: api-tls
  rules:
    - host: api.monentreprise.fr
      ...

# Suivre l'état d'un Certificate
kubectl get certificate -A
kubectl describe certificate wildcard-cert -n production
 
# Voir les challenges ACME en cours
kubectl get challenges -A
kubectl get orders -A

Rate limits Let’s Encrypt

Limite	Valeur	Notes
Certificats par domaine enregistré	50 / semaine	Ex: 50 certs pour `*.monentreprise.fr`
Doublons (même noms)	5 / semaine	Renouvellements non comptés
Échecs de validation	5 / heure, 15 / 3h	Éviter les tests en production
Comptes par IP	10 / 3h	Pour les nouvelles inscriptions
Environnement de staging	Pas de limite	Toujours tester en staging d’abord

# Toujours utiliser le staging pour les tests !
certbot certonly --staging --standalone -d example.com
 
# ClusterIssuer staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory

En relation avec

Certificats — Vue d’ensemble — types et usages des certificats
PKI — Infrastructure à Clés Publiques — Let’s Encrypt est une CA publique de la PKI mondiale
Cycle de vie et révocation — renouvellement et révocation avec ACME
DNS - TXT — le challenge DNS-01 crée un enregistrement TXT
DNS - CAA — contrôler quelles CA peuvent émettre pour un domaine
cert-manager — automatisation complète dans Kubernetes

abla.adem

Recent Notes

Agents — Vue d'ensemble

Agents autonomes

Prompt Engineering — Vue d'ensemble

CARE

Explorer