cert-manager : Let's Encrypt depuis K8S - HTTP01

Ce guide détaille la mise en œuvre de certificats TLS automatisés via Let's Encrypt et cert-manager sur un cluster Kubernetes SdV, en utilisant la méthode de validation HTTP01. Il s'adresse aux équipes DevOps/Ops/SRE souhaitant sécuriser leurs applications web avec HTTPS.

Introduction

Let's Encrypt est une autorité de certification (CA) gratuite, automatisée et ouverte, permettant de générer des certificats TLS pour sécuriser les communications HTTPS. Sur Kubernetes, cert-manager automatise l'ensemble du cycle de vie des certificats : demande, validation, renouvellement et révocation.

Concepts clés

Méthode de validation HTTP01

La validation HTTP01 repose sur la création temporaire d'un fichier accessible publiquement via HTTP à l'URL :

http://<votre-domaine>/.well-known/acme-challenge/<token>

Let's Encrypt vérifie que vous contrôlez le domaine en accédant à cette URL. Cette méthode nécessite :

• Un domaine public pointant vers l'IP de l'Ingress public du cluster
• Un accès HTTP (port 80) ouvert depuis Internet
• Un Ingress Controller fonctionnel

Issuer vs ClusterIssuer

• Issuer : Ressource namespacée, utilisable uniquement dans son namespace
• ClusterIssuer : Ressource cluster-wide, utilisable depuis tous les namespaces

Staging vs Production

Let's Encrypt propose deux environnements :

Le mode staging permet de valider votre configuration sans risquer d'atteindre les limites de production.

Prérequis

Avant de démarrer, assurez-vous de disposer de :

• Helm 3.x (guide d'installation)
• kubectl configuré avec un kubeconfig valide pointant vers votre cluster SdV
• Une entrée DNS publique (enregistrement A ou CNAME) pointant vers l'IP de l'Ingress public du cluster
• Droits d'administration sur le cluster (création de namespaces, CRDs, ClusterRoles)
• Accès HTTP (port 80) depuis Internet vers l'Ingress public (pour la validation ACME)

Installation de cert-manager

cert-manager est un composant central pour la gestion automatisée des certificats TLS sur Kubernetes. Il s'installe via Helm et déploie plusieurs contrôleurs, CRDs (Custom Resource Definitions) et webhooks.

helm repo add jetstack https://charts.jetstack.io --force-update
helm repo update

cat <<EOF > values.yaml
# Installation des CRDs (Custom Resource Definitions)
# Obligatoire pour utiliser les ressources Certificate, Issuer, ClusterIssuer
installCRDs: true
 
# Désactivation de Prometheus (optionnel)
# Activez si vous utilisez Prometheus pour la supervision
prometheus:
  enabled: false
  serviceMonitor:
    enabled: true
 
# Ressources recommandées pour la production
resources:
  requests:
    cpu: 10m
    memory: 32Mi
  limits:
    cpu: 100m
    memory: 128Mi
EOF
 
helm upgrade --install      \
  --namespace cert-manager  \
  --create-namespace        \
  --version "v1.14.2"       \
  --values values.yaml      \
  cert-manager              \
  jetstack/cert-manager

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cert-manager-clusterissuer-http01-staging
spec:
  acme:
    # Serveur ACME de staging Let's Encrypt
    server: https://acme-staging-v02.api.letsencrypt.org/directory
 
    # Email de contact pour les notifications Let's Encrypt
    # (expiration, renouvellement, sécurité)
    email: admin@example.com
 
    # Secret Kubernetes pour stocker la clé privée du compte ACME
    privateKeySecretRef:
      name: cert-manager-clusterissuer-http01-staging
 
    # Méthode de validation : HTTP01 via Ingress
    solvers:
    - http01:
        ingress:
          ingressClassName: public

kubectl apply -f cert-manager-clusterissuer-http01-staging.yaml
kubectl apply -f cert-manager-clusterissuer-http01-production.yaml

kubectl get clusterissuer cert-manager-clusterissuer-http01-staging -o wide
kubectl describe clusterissuer cert-manager-clusterissuer-http01-staging
kubectl get clusterissuer cert-manager-clusterissuer-http01-production -o wide
kubectl describe clusterissuer cert-manager-clusterissuer-http01-production

kubectl get pods -n cert-manager

kubectl get crd | grep cert-manager

Mise en œuvre dans un projet

Cette section illustre le déploiement complet d'une application avec génération automatique de certificats Let's Encrypt. Le processus se décompose en trois étapes :

1. Déploiement d'une application exemple (serveur nginx)
2. Génération d'un certificat de staging (validation de la configuration)
3. Génération d'un certificat de production (certificat valide et reconnu)

Déploiement de l'application exemple

Nous utilisons un serveur nginx simple servant une page HTML statique. Cette application démontre l'intégration complète : application → service → ingress → certificat TLS.

Ressources Kubernetes déployées

• Namespace : Isolation logique du projet
• ConfigMap : Contenu HTML de la page
• Deployment : Contrôleur de pods nginx
• Service : Exposition interne du serveur nginx
• Ingress : Exposition externe via FQDN

Manifeste complet

apiVersion: v1
kind: Namespace
metadata:
  name: letsencrypt-example
  labels:
    project: letsencrypt-demo
  annotations:
    description: "Démonstration cert-manager avec Let's Encrypt HTTP01"

Déploiement

Une fois le manifeste personnalisé avec votre FQDN, appliquez-le :

kubectl apply -f namespace.yaml
kubectl apply -f configmap.yaml
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml

Sortie attendue :

namespace/letsencrypt-example created
configmap/nginx-html created
deployment.apps/nginx created
service/nginx-svc created
ingress.networking.k8s.io/nginx-ingress created

Vérification du déploiement

Vérifiez que tous les composants sont opérationnels :

# Vérifier les pods
kubectl get pods -n letsencrypt-example
 
# Vérifier le service
kubectl get svc -n letsencrypt-example
 
# Vérifier l'Ingress
kubectl get ingress -n letsencrypt-example

Testez l'accès HTTP (non sécurisé) :

curl -I http://[FQDN]/

Vous devriez obtenir un code HTTP/1.1 200 OK.

Génération d'un certificat TLS en staging

Comprendre les Issuers et ClusterIssuers

Pour que cert-manager puisse traiter vos demandes de certificats TLS, il faut déclarer un Issuer (namespacé) ou un ClusterIssuer (cluster-wide).

Let's Encrypt propose deux environnements ACME :

Configuration de l'Ingress pour cert-manager

Pour déclencher la génération automatique du certificat, modifiez l'Ingress en ajoutant :

1. Annotation cert-manager.io/cluster-issuer : Indique quel ClusterIssuer utiliser
2. Section tls : Définit les domaines concernés et le nom du Secret qui contiendra le certificat

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: letsencrypt-example
  labels:
    app: nginx
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    # Annotation clé pour cert-manager
    cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-staging
spec:
  ingressClassName: public
  # Section TLS
  tls:
  - secretName: nginx-tls  # Nom du Secret à créer automatiquement
    hosts:
    - [FQDN]  # Domaine à sécuriser
  rules:
  - host: [FQDN]
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80

Appliquez la modification :

kubectl apply -f ingress-tls-staging.yaml

Ou éditez directement l'Ingress existant :

kubectl edit ingress nginx-ingress -n letsencrypt-example

Suivi de la génération du certificat

Dès que l'Ingress est modifié, cert-manager détecte l'annotation et déclenche automatiquement :

1. Création d'une ressource Certificate
2. Création d'une CertificateRequest
3. Création d'un Order (demande ACME)
4. Création d'un Challenge (validation HTTP01)
5. Création temporaire d'un pod solver et modification de l'Ingress
6. Validation par Let's Encrypt via http://[FQDN]/.well-known/acme-challenge/<token>
7. Emission du certificat et stockage dans le Secret

Suivez la progression :

# Vérifier les événements de l'Ingress
kubectl describe ingress nginx-ingress -n letsencrypt-example
 
# Vérifier la ressource Certificate
kubectl get certificate -n letsencrypt-example
kubectl describe certificate nginx-tls -n letsencrypt-example
 
# Suivre les challenges HTTP01
kubectl get challenge -n letsencrypt-example
kubectl describe challenge -n letsencrypt-example
 
# Vérifier les logs cert-manager
kubectl logs -n cert-manager -l app=cert-manager -f

Lorsque le certificat est généré, vous verrez dans les événements :

Normal  CreateCertificate  Successfully created Certificate "nginx-tls"
Normal  Issuing            Issuing certificate as Secret does not exist
Normal  Generated          Stored new private key in temporary Secret
Normal  Requested          Created new CertificateRequest
Normal  Issued             Certificate issued successfully

Vérification du Secret et du certificat

Vérifiez que le Secret TLS a bien été créé :

kubectl get secret nginx-tls -n letsencrypt-example
kubectl describe secret nginx-tls -n letsencrypt-example

Le Secret de type kubernetes.io/tls contient deux clés : tls.crt (certificat) et tls.key (clé privée).

Inspectez le certificat généré :

kubectl get secret nginx-tls -n letsencrypt-example -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout

Points à vérifier :

• Issuer : Fake LE Intermediate X1 (staging)
• Subject : CN=[FQDN]
• Validity : Date d'expiration (90 jours par défaut)
• Subject Alternative Name : DNS:[FQDN]

Test dans le navigateur

Accédez à https://[FQDN]/ dans votre navigateur.

Vous obtiendrez une erreur de certificat :

Chrome  : NET::ERR_CERT_AUTHORITY_INVALID
Firefox : SEC_ERROR_UNKNOWN_ISSUER
 
Chaîne de certification :
Fake LE Root X1
  └─ Fake LE Intermediate X1
      └─ [FQDN]

C'est normal : le certificat de staging n'est pas signé par une CA reconnue. Il sert uniquement à valider la configuration.

Génération d'un certificat TLS en production

Une fois la configuration validée en staging, basculez vers le ClusterIssuer de production cert-manager-clusterissuer-http01-production pour obtenir un certificat reconnu par les navigateurs.

Modification de l'Ingress

Il suffit de changer l'annotation cert-manager.io/cluster-issuer pour pointer vers le ClusterIssuer de production :

kubectl edit ingress nginx-ingress -n letsencrypt-example

Modifiez uniquement l'annotation :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: letsencrypt-example
  labels:
    app: nginx
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    # Basculement vers production
    cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-production
spec:
  ingressClassName: public
  tls:
  - secretName: nginx-tls
    hosts:
    - [FQDN]
  rules:
  - host: [FQDN]
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80

Suivi de la génération

Suivez le processus comme pour le staging :

# Surveiller la mise à jour du certificat
kubectl get certificate nginx-tls -n letsencrypt-example -w
 
# Vérifier les événements
kubectl describe certificate nginx-tls -n letsencrypt-example
 
# Voir les challenges
kubectl get challenge -n letsencrypt-example

Événement attendu dans l'`Ingress@ :

Normal  UpdateCertificate  Successfully updated Certificate "nginx-tls"

Vérification du certificat production

Inspectez le nouveau certificat :

kubectl get secret nginx-tls -n letsencrypt-example -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout | grep -A2 "Issuer\|Subject\|Validity"

Points à vérifier :

• Issuer : CN=R3, O=Let's Encrypt, C=US (production)
• Subject : CN=[FQDN]
• Validity : Expire dans 90 jours

Vérifiez la chaîne complète :

echo | openssl s_client -servername [FQDN] -connect [FQDN]:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Test final dans le navigateur

Accédez à https://[FQDN]/ dans votre navigateur.

Le certificat doit être valide et reconnu :

• Cadenas vert/icône de sécurité
• Aucun avertissement de sécurité
• Chaîne de certification complète et valide

Chaîne de certification :
ISSRG Root X1 (DST Root CA X3)
  └─ R3 (Let's Encrypt Authority X3)
      └─ [FQDN]

Consultez les détails du certificat (clic sur le cadenas) pour vérifier :

• Validité : 90 jours
• Emis par : Let's Encrypt (R3 ou R11 selon la période)
• Algorithme : RSA 2048 bits ou ECDSA

Validation SSL/TLS avec des outils externes

Pour une analyse complète de la configuration SSL/TLS :

# Test avec curl
curl -vI https://[FQDN]/
 
# Test avec testssl.sh (outil d'audit SSL)
docker run --rm drwetter/testssl.sh [FQDN]
 
# Analyse avec SSL Labs (en ligne)
# https://www.ssllabs.com/ssltest/analyze.html?d=[FQDN]

Troubleshooting

Cette section recense les problèmes courants rencontrés lors de la mise en œuvre de cert-manager avec Let's Encrypt.

Le certificat n'est pas généré

Symptômes

• Le Secret TLS n'existe pas après plusieurs minutes
• Aucun événement CreateCertificate dans l'Ingress
• Le Pod cert-manager redémarre en boucle

Diagnostic

# Vérifier l'état du Certificate
kubectl get certificate -n letsencrypt-example
kubectl describe certificate nginx-tls -n letsencrypt-example
 
# Vérifier les CertificateRequest
kubectl get certificaterequest -n letsencrypt-example
kubectl describe certificaterequest -n letsencrypt-example
 
# Vérifier les logs cert-manager
kubectl logs -n cert-manager -l app=cert-manager --tail=100
 
# Vérifier que les CRDs sont installées
kubectl get crd | grep cert-manager

Solutions

1. CRDs manquantes : Réinstallez cert-manager avec installCRDs: true
2. Annotation incorrecte : Vérifiez cert-manager.io/cluster-issuer (et non cert-manager.io/issuer pour un ClusterIssuer)
3. ClusterIssuer non prêt : kubectl get clusterissuer doit afficher Ready: True
4. Problème RBAC : cert-manager n'a peut-être pas les droits nécessaires

Challenge HTTP01 échoue

Symptômes

• Le challenge reste en état Pending ou Processing
• Erreur dans les événements : Waiting for HTTP-01 challenge propagation
• Let's Encrypt ne peut pas valider le domaine

Diagnostic

# Voir l'état des challenges
kubectl get challenge -n letsencrypt-example
kubectl describe challenge -n letsencrypt-example
 
# Vérifier que le pod solver est créé
kubectl get pods -n letsencrypt-example
 
# Tester l'accès au challenge depuis l'extérieur
curl -I http://[FQDN]/.well-known/acme-challenge/test
 
# Vérifier les logs du webhook
kubectl logs -n cert-manager -l app=cert-manager-webhook

Solutions

1. DNS mal configuré : Vérifiez que le FQDN pointe bien vers l'IP publique de l'Ingress

   Terminal

   nslookup [FQDN]
   dig [FQDN] +short

2. Port 80 non accessible : Assurez-vous que le port 80 est ouvert depuis Internet

   Terminal

   curl -I http://[FQDN]
   telnet [FQDN] 80

3. Ingress Controller ne route pas le trafic : Vérifiez la configuration de l'Ingress Controller

   Terminal

   kubectl get ingress -A
   kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

4. Firewall/WAF bloque Let's Encrypt : Let's Encrypt utilise des IPs publiques variables. Vérifiez les règles de pare-feu.

Rate limit atteint (production)

Symptômes

• Erreur : too many certificates already issued
• Impossible de générer un nouveau certificat
• Erreur 429 Too Many Requests dans les logs

Diagnostic

kubectl describe certificaterequest -n letsencrypt-example | grep -i "rate limit"
kubectl logs -n cert-manager -l app=cert-manager | grep -i "rate limit"

Solutions

1. Attendre : Les limites Let's Encrypt sont temporaires (1 semaine)
2. Utiliser staging : Basculez temporairement vers le ClusterIssuer staging
3. Consulter les limites : Documentation Let's Encrypt Rate Limits
4. Réutiliser les certificats : Ne supprimez pas les Secrets TLS inutilement

Les limites principales :

• 50 certificats/domaine enregistré/semaine
• 5 certificats/FQDN/semaine (renouvellements inclus)
• 300 comptes/IP/3 heures

Certificat expiré ou non renouvelé

Symptômes

• Erreur SSL dans le navigateur : NET::ERR_CERT_DATE_INVALID
• Le certificat a dépassé sa date d'expiration
• Aucun événement de renouvellement dans les logs

Diagnostic

# Vérifier la date d'expiration
kubectl get secret nginx-tls -n letsencrypt-example -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates
 
# Vérifier l'état du Certificate
kubectl get certificate nginx-tls -n letsencrypt-example -o yaml | grep -A5 "status:"
 
# Vérifier les logs de renouvellement
kubectl logs -n cert-manager -l app=cert-manager | grep -i "renew"

Solutions

1. Forcer le renouvellement : Supprimez le Secret pour déclencher une nouvelle génération

   Terminal

   kubectl delete secret nginx-tls -n letsencrypt-example

   cert-manager recréera automatiquement le certificat.

2. Vérifier la configuration du Certificate : Le renouvellement automatique se fait 30 jours avant expiration

   Terminal

   kubectl get certificate nginx-tls -n letsencrypt-example -o yaml

3. Problème de webhook : Redémarrez le webhook cert-manager

   Terminal

   kubectl rollout restart deployment cert-manager-webhook -n cert-manager

Erreur "self-signed certificate in certificate chain"

Symptômes

• Erreur lors d'opérations kubectl ou curl : x509: certificate signed by unknown authority
• Le certificat staging est utilisé alors que production était demandé

Solutions

1. Vérifier l'annotation de l'Ingress : Assurez-vous d'utiliser cert-manager-clusterissuer-http01-production
2. Vider le cache du Secret : Supprimez et recréez le certificat
3. Vérifier la chaîne du certificat :
   Terminal

   kubectl get secret nginx-tls -n letsencrypt-example -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout | grep "Issuer"

Bonnes pratiques

Gestion des certificats

Utiliser des ClusterIssuers

Privilégiez ClusterIssuer plutôt que Issuer pour une configuration centralisée et réutilisable dans tous les namespaces.

# ✅ Recommandé
cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-production
 
# ⚠️ Moins flexible
cert-manager.io/issuer: letsencrypt-production

Toujours tester en staging

Validez votre configuration avec le ClusterIssuer de staging avant de passer en production pour éviter d'atteindre les rate limits.

# Phase 1 : Validation
cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-staging
 
# Phase 2 : Production
cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-production

Sauvegarder la clé privée ACME

La clé privée du compte ACME (stockée dans le Secret référencé par privateKeySecretRef) est critique. Incluez-la dans vos sauvegardes Velero :

spec:
  acme:
    privateKeySecretRef:
      name: letsencrypt-production-account-key  # À sauvegarder !

Sécurité

Limiter l'accès aux Secrets TLS

Les Secrets TLS contiennent des clés privées sensibles. Appliquez des RBAC stricts :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cert-viewer
  namespace: letsencrypt-example
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["nginx-tls"]
  verbs: ["get", "list"]

Restreindre les domaines

Dans un environnement multi-tenant, limitez les domaines pouvant être demandés via cert-manager pour éviter les abus.

Activer les notifications

Configurez un email valide dans le ClusterIssuer pour recevoir les alertes Let's Encrypt (expiration, problèmes de renouvellement).

spec:
  acme:
    email: devops@votreentreprise.fr  # Email d'alerte

Performance et fiabilité

Définir des ressources pour cert-manager

Assurez des requests et limits appropriées pour éviter l'éviction des pods cert-manager :

resources:
  requests:
    cpu: 20m
    memory: 64Mi
  limits:
    cpu: 200m
    memory: 256Mi

Superviser cert-manager

Activez Prometheus pour monitorer cert-manager :

prometheus:
  enabled: true
  servicemonitor:
    enabled: true

Métriques clés à surveiller :

• certmanager_certificate_expiration_timestamp_seconds : Date d'expiration des certificats
• certmanager_certificate_ready_status : État des certificats
• certmanager_http_acme_client_request_count : Nombre de requêtes ACME

Configurer des alertes

Créez des alertes Prometheus pour anticiper les problèmes :

- alert: CertificateExpirationSoon
  expr: (certmanager_certificate_expiration_timestamp_seconds - time()) < (7 * 24 * 3600)
  annotations:
    summary: "Certificat expire dans moins de 7 jours"

Architecture

Séparer les environnements

Utilisez des Namespaces distincts pour dev, staging et production :

# dev : certificats staging
cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-staging
 
# prod : certificats production
cert-manager.io/cluster-issuer: cert-manager-clusterissuer-http01-production

Documenter les domaines

Maintenez un inventaire des certificats et domaines gérés :

metadata:
  annotations:
    description: "Certificat TLS pour l'application Ghost"
    owner: "equipe-devops"
    expires: "Auto-renew 30j avant expiration"

Renouvellement automatique

cert-manager gère automatiquement le renouvellement des certificats Let's Encrypt. Voici comment fonctionne ce mécanisme.

Principe

• Les certificats Let's Encrypt ont une validité de 90 jours
• cert-manager les renouvelle automatiquement 30 jours avant expiration
• Le renouvellement est transparent : aucune interruption de service

Vérifier l'échéance de renouvellement

# Afficher la date d'expiration
kubectl get certificate nginx-tls -n letsencrypt-example -o jsonpath='{.status.notAfter}'
 
# Calculer les jours restants
kubectl get secret nginx-tls -n letsencrypt-example -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -enddate

Forcer un renouvellement manuel

Si nécessaire, déclenchez manuellement un renouvellement :

# Méthode 1 : Supprimer le Secret (cert-manager le recréera)
kubectl delete secret nginx-tls -n letsencrypt-example
 
# Méthode 2 : Annoter le Certificate pour forcer le renouvellement
kubectl annotate certificate nginx-tls -n letsencrypt-example cert-manager.io/issue-temporary-certificate="true" --overwrite

Surveiller les renouvellements

Consultez les logs pour vérifier les renouvellements :

kubectl logs -n cert-manager -l app=cert-manager | grep -i "renew\|issued"

Événements attendus :

Issuing certificate as Secret does not contain a certificate
Certificate issued successfully

Nettoyage et désinstallation

Supprimer l'application exemple

# Supprimer toutes les ressources du namespace
kubectl delete namespace letsencrypt-example
 
# Ou supprimer ressource par ressource
kubectl delete ingress nginx-ingress -n letsencrypt-example
kubectl delete service nginx-svc -n letsencrypt-example
kubectl delete deployment nginx -n letsencrypt-example
kubectl delete configmap nginx-html -n letsencrypt-example
kubectl delete secret nginx-tls -n letsencrypt-example

Supprimer les ClusterIssuers (optionnel)

kubectl delete clusterissuer cert-manager-clusterissuer-http01-staging
kubectl delete clusterissuer cert-manager-clusterissuer-http01-production

Désinstaller cert-manager

# Désinstaller via Helm
helm uninstall cert-manager -n cert-manager
 
# Supprimer les CRDs (attention : supprime toutes les ressources Certificate/Issuer)
kubectl delete crd certificates.cert-manager.io
kubectl delete crd certificaterequests.cert-manager.io
kubectl delete crd challenges.cert-manager.io
kubectl delete crd clusterissuers.cert-manager.io
kubectl delete crd issuers.cert-manager.io
kubectl delete crd orders.cert-manager.io
 
# Supprimer le namespace
kubectl delete namespace cert-manager

Ressources complémentaires

• Documentation officielle cert-manager
• Let's Encrypt - Documentation
• Rate Limits Let's Encrypt
• Chart Helm cert-manager
• Guide Ingress HAProxy sur SdV
• Guide cert-manager DNS01

Conclusion

Vous disposez désormais d'une configuration complète pour générer automatiquement des certificats TLS Let's Encrypt sur votre cluster Kubernetes SdV via cert-manager et la méthode de validation HTTP01.

Points clés à retenir :

• Testez toujours en staging avant la production
• Utilisez des ClusterIssuers pour mutualiser la configuration
• Surveillez les renouvellements automatiques (30 jours avant expiration)
• Attention aux rate limits Let's Encrypt en production
• Sauvegardez les Secrets TLS et la clé ACME

Pour des besoins avancés (certificats wildcard, Ingress privé), consultez le guide DNS01.