wiki/Catalogue-Self-Hosted/apps/app-cert-warden.md

---

title: Cert Warden created: 2026-06-06 updated: 2026-06-06 type: app tags: [catalogue, certificats, acme, lets-encrypt, tls, automatisation, go] confidence: high contested: false sources: [https://selfh.st/apps/?tag=Reverse+Proxy, https://github.com/gregtwallace/certwarden]

🚦 Cert Warden

Client ACME centralisé : génère et distribue automatiquement des certificats Let's Encrypt vers tous vos services via API key. Idéal pour les infrastructures multi-serveurs qui veulent découpler la gestion TLS du reverse proxy principal.

📋 Informations Générales

Champ	Valeur
Site web	certwarden.com
GitHub	gregtwallace/certwarden
License	BSD-3-Clause
Langage	Dockerfile (orchestration), Go (backend, repo séparé), TypeScript (frontend, repo séparé)
Étoiles GitHub	584 ⭐
Dernière MAJ	2026-05-22 (v0.29.5)
Catégorie	[[cat-reverse-proxy

📝 Description

Cert Warden (anciennement Cert Warden par gregtwallace) est un client ACME centralisé : au lieu que chaque service (reverse proxy, NAS, serveur mail, etc.) gère ses propres certificats Let's Encrypt indépendamment, un seul point les génère, les stocke, et les sert via une API authentifiée par clés aux consommateurs qui en ont besoin.

C'est la réponse au problème classique : "j'ai 3 reverse proxy et 2 services qui ont besoin de TLS, et je veux que tous les certificats soient renouvelés au même endroit, monitorés, et téléchargeables simplement".

Caractéristiques principales :

• ✅ Client ACME Let's Encrypt (ou toute CA ACME-compatible : Buypass, ZeroSSL, etc.)
• ✅ API REST pour que les services fetch leurs certificats par API key
• ✅ Providers de validation multiples : HTTP-01 et DNS-01
• ✅ DNS providers : Cloudflare, Route53, DigitalOcean, Hetzner, OVH, Porkbun, etc.
• ✅ Stockage centralisé des certs + clés privées (chiffré au repos)
• ✅ Distribution automatique : les clients fetch en HTTP(S) leur cert + key
• ✅ Alertes : webhook/email sur renouvellement, échec, expiration proche
• ✅ Web UI pour visualiser/manager les certs (frontend séparé)
• ✅ Client léger dédié (certwarden-client) pour distribuer sur des serveurs distants
• ✅ Cross-platform : Linux, ARM (Raspberry Pi), Windows, macOS

Public cible : administrateurs d'infrastructures multi-serveurs (home lab avec plusieurs machines, PME, associations) qui veulent un point unique de gestion TLS au lieu de dupliquer la config certbot sur 5 serveurs. Particulièrement pertinent quand on a des services qui ne supportent pas nativement ACME (synology, vieux nginx custom, etc.).

🚀 Installation

Option 1 : Docker Compose (recommandé)

# docker-compose.yml
version: '3.8'
services:
  certwarden:
    image: ghcr.io/gregtwallace/certwarden:latest
    container_name: certwarden
    restart: unless-stopped
    ports:
      - "8080:8080"   # web UI + API
    volumes:
      - ./data:/app/data   # certs, db, config
    environment:
      - TZ=Europe/Paris
    networks:
      - proxy

networks:
  proxy:
    external: true

Variante Traefik (exposer derrière Traefik + auth)

# docker-compose.yml (variante)
version: '3.8'
services:
  certwarden:
    image: ghcr.io/gregtwallace/certwarden:latest
    container_name: certwarden
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    environment:
      - TZ=Europe/Paris
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.certwarden.rule=Host(`certs.example.com`)"
      - "traefik.http.routers.certwarden.entrypoints=websecure"
      - "traefik.http.routers.certwarden.tls.certresolver=letsencrypt"
      - "traefik.http.services.certwarden.loadbalancer.server.port=8080"
      - "traefik.http.routers.certwarden.middlewares=auth-basique@docker"
    networks:
      - proxy

networks:
  proxy:
    external: true

Option 2 : Client Cert Warden sur un serveur distant

# Sur une machine distante qui fetch ses certs via l'API Cert Warden
version: '3.8'
services:
  certwarden-client:
    image: ghcr.io/gregtwallace/certwarden-client:latest
    container_name: certwarden-client
    restart: unless-stopped
    volumes:
      - /etc/ssl/private:/certs   # destination des certs fetched
    environment:
      - CW_SERVER=https://certs.example.com
      - CW_API_KEY=your-api-key-here
      - CW_CERT_NAMES=example.com,api.example.com
      - CW_AUTO_RELOAD=true

⚙️ Configuration Initiale

1. Lancer le conteneur et accéder à http://YOUR_HOST:8080.
2. Compte admin : créé au premier démarrage (consulter les logs du conteneur pour le password initial).
3. Ajouter un ACME Account : menu "ACME Accounts" → provider (Let's Encrypt prod/staging) + contact email.
4. Configurer un Challenge Provider : DNS-01 (avec token API du provider DNS) ou HTTP-01 (nécessite le port 80 ouvert).
5. Créer un Certificate Profile : domains (SAN), validation method, renewal window.
6. Créer un Client (API key) : chaque service qui fetch ses certs aura sa propre clé.
7. Tester le fetch : curl -H "X-API-Key: your-key" https://certs.example.com/certificates/example.com retourne le bundle complet (cert + chain + key).
8. Intégrer dans le service final : nginx, Caddy, Synology DSM, etc. via cron, systemd timer, ou le client dédié.

🎯 Pattern typique : Traefik/Caddy font leur propre ACME (DNS-01 avec Cloudflare) → les services qui ne supportent pas ACME (Synology, vieux apps) fetchent via Cert Warden.

🔄 Alternatives

Open Source

• Caddy — ACME automatique intégré (mais pas centralisé)
• Traefik — ACME automatique intégré (mais pas centralisé)
• acme.sh — script bash ACME mature, fichiers statiques
• Certbot — client ACME de référence (EFF)
• Step-CA — CA privée complète (cf. smallstep)
• HashiCorp Vault PKI — pour les infrastructures HashiCorp
• Caddy + DNS module — centralisation possible via API DNS

Propriétaires (ce que Cert Warden remplace)

• Cloudflare SSL/TLS (avec mode "Full" et API tokens)
• AWS Certificate Manager + ALB/CloudFront
• DigiCert CertCentral (entreprise)
• Venafi (entreprise)
• Google Trust Services (managed CA)

Comparaison rapide

Critère	Cert Warden	acme.sh	Caddy intégré
Centralisation	✅ API centrale	❌ (fichiers par host)	❌ (par instance)
API distribution	✅	❌ (fs/scp)	❌
Web UI	✅	❌	✅ (Caddy)
DNS providers	✅ (12+)	✅ (150+)	✅ (50+)
Multi-serveur	✅ Natif	⚠️ DIY	❌
License	BSD-3-Clause	MIT	Apache-2.0
Stars	584	43k+	73k

Verdict : Cert Warden pour qui veut centraliser la distribution de certs vers des services hétérogènes (NAS, IoT, vieux services). acme.sh pour qui a peu de serveurs et accepte de scripter. Caddy/Traefik pour qui peut tout faire gérer par le reverse proxy lui-même.

🔐 Sécurité

• Stockage chiffré au repos : clés privées dans ./data à sécuriser (chmod 700)
• API keys distinctes par client : rotation facilitée, révocation immédiate
• Pas d'exposition Internet du port 8080 sans auth : toujours derrière Traefik + basicauth/Authentik
• Renouvellement proactif : fenêtre par défaut 30 jours avant expiration → marge de sécurité
• Logs d'accès API : auditer qui fetche quoi
• ⚠️ Si quelqu'un obtient l'API key + accès au port, il peut télécharger votre clé privée → 2FA sur l'UI et restrictions IP recommandées
• Webhook secrets : signer les webhooks d'alerte pour éviter les faux positifs
• Backups réguliers de ./data : si vous perdez la DB, vous perdez les certs

📚 Ressources

• Site officiel
• Documentation GitHub
• Cert Warden Client (consommateur)
• Forum Cert Warden
• Reddit r/selfhosted: TLS multi-serveur

Pages Liées

• cat-reverse-proxy — Catégorie Reverse Proxy
• app-caddy — ACME automatique par reverse proxy
• app-traefik — Idem, ACME intégré
• tls-https — Concepts TLS/HTTPS
• comparatif-reverse-proxy — Comparaison détaillée
• certbot — Alternative script bash