# Clients ACMEUtiliser des clients ACME standard avec l'AC interne — ce qui est identique à Let's Encrypt, ce qui diffère.

## Ce qui reste identique à Let's Encrypt

Si vous avez déjà obtenu un certificat Let's Encrypt, vous
pouvez déjà utiliser l'AC interne. Le protocole est identique —
ACME RFC 8555. Les clients que vous connaissez déjà
fonctionnent sans modification.

Identique :

- Challenges HTTP-01 et DNS-01.
- Enregistrement de compte et gestion de clé.
- Durée par défaut de 90 jours.
- Renouvellement automatique à 60 jours.
- Certificats wildcard via DNS-01.

## Ce qui diffère

Deux petites différences, toutes deux des étapes de setup
ponctuelles :

1. **L'URL du répertoire ACME** pointe sur l'AC interne, pas sur
   `https://acme-v02.api.letsencrypt.org/directory`.
2. **Le certificat racine** de l'AC interne doit être approuvé
   par le client qui fait la demande. Cela se met en place via
   gestion de configuration (Ansible, Puppet, MDM) lors du
   provisioning des hôtes.

C'est toute la différence. Tout le reste est le même workflow
Let's Encrypt que vous connaissez.

## Pointer votre client sur l'AC interne

Le endpoint ACME interne est publié à une URL interne stable
(typiquement `https://acme.example.internal/acme/acme/directory`,
mais le chemin exact dépend de votre déploiement). Voici des
recettes pour les clients courants.

### `certbot`

```sh
certbot --server https://acme.example.internal/acme/acme/directory \
        --email ops@example.internal \
        --no-eff-email \
        --agree-tos \
        certonly --standalone -d service.example.internal
```

Au renouvellement, le flag `--server` est persisté dans
`renewal/*.conf`, donc le cron périodique `certbot renew` le
reprend automatiquement.

### `acme.sh`

```sh
acme.sh --register-account \
        --server https://acme.example.internal/acme/acme/directory \
        -m ops@example.internal

acme.sh --issue \
        --server https://acme.example.internal/acme/acme/directory \
        --standalone \
        -d service.example.internal
```

### `lego`

```sh
lego --server=https://acme.example.internal/acme/acme/directory \
     --email=ops@example.internal \
     --domains=service.example.internal \
     --http run
```

### Caddy

Dans votre `Caddyfile` :

```caddy
{
  acme_ca https://acme.example.internal/acme/acme/directory
  email ops@example.internal
}

service.example.internal {
  reverse_proxy localhost:8080
}
```

Caddy obtient et renouvelle le certificat automatiquement.

### Traefik

Dans votre configuration dynamique :

```yaml
certificatesResolvers:
  internal:
    acme:
      caServer: "https://acme.example.internal/acme/acme/directory"
      email: ops@example.internal
      storage: /etc/traefik/acme.json
      httpChallenge:
        entryPoint: web
```

Référencer `certResolver: internal` depuis vos définitions de
routeur.

## Installer le certificat racine sur les clients

Pour que les certificats émis par l'AC soient approuvés sans
avertissement, la racine de l'AC doit être dans le store de
confiance système de chaque hôte qui verra les certificats.

### Linux (famille Debian/Devuan)

```sh
sudo cp internal-ca-root.crt /usr/local/share/ca-certificates/internal-ca-root.crt
sudo update-ca-certificates
```

### Linux (famille RHEL)

```sh
sudo cp internal-ca-root.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
```

### OpenBSD / FreeBSD

```sh
# OpenBSD
sudo install -m 0644 internal-ca-root.crt /etc/ssl/internal-ca-root.crt
sudo cat /etc/ssl/cert.pem internal-ca-root.crt > /etc/ssl/cert.pem.new
sudo mv /etc/ssl/cert.pem.new /etc/ssl/cert.pem
```

### macOS

```sh
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain internal-ca-root.crt
```

### Windows

```cmd
certutil.exe -addstore -f "ROOT" internal-ca-root.crt
```

Pour les navigateurs qui maintiennent leurs propres stores de
confiance (Firefox), la racine doit aussi être importée via
Paramètres → Vie privée → Certificats → Autorités.

Cette installation est normalement gérée par la gestion de
configuration. Le faire à la main est ok pour un cas unique mais
ne passe pas à l'échelle pour une flotte.

## Certificats wildcard

Les wildcards sont émis via le challenge DNS-01 — le client
prouve le contrôle d'un domaine en créant un enregistrement TXT.
Cela fonctionne pour des domaines purement internes parce que
l'AC interne peut valider des enregistrements TXT sur n'importe
quel serveur DNS que vous contrôlez.

Exemple avec `acme.sh` utilisant le provider BIND nsupdate :

```sh
acme.sh --issue \
        --server https://acme.example.internal/acme/acme/directory \
        --dns dns_nsupdate \
        -d '*.example.internal' \
        -d 'example.internal'
```

Vous aurez besoin que le provider nsupdate soit configuré contre
votre DNS interne — voir la documentation `acme.sh` pour les
variables d'environnement spécifiques.

## Renouvellement

Le renouvellement fonctionne comme avec Let's Encrypt : le client
vérifie la validité restante et renouvelle quand sous le seuil
(60 jours pour un cert de 90 jours).

Pour la plupart des déploiements, le cron de renouvellement
existant (`certbot renew`, `acme.sh --cron`, le renouvellement
auto de Caddy) marche tout seul.

En cas d'échecs de renouvellement :

1. **L'URL du répertoire est-elle toujours joignable ?** Un
   changement réseau peut avoir cassé le chemin du client à l'AC.
2. **Le certificat racine a-t-il expiré ou été tourné ?** Les
   racines sont typiquement valides 10 ans ; les intermédiaires
   pour des périodes plus courtes. Une rotation qui n'a pas
   propagé à tous les clients se manifestera par des échecs de
   renouvellement.
3. **Le type de challenge est-il toujours approprié ?** Un
   service qui était joignable pour HTTP-01 peut maintenant se
   trouver derrière un load balancer qui casse la réponse du
   challenge.

## Limites et politiques

L'AC interne applique des politiques par compte — quels domaines
chaque compte peut demander des certificats, quelle durée maximum
est autorisée, quels types de challenge sont acceptés.

Si une requête qui marchait hier échoue soudainement avec une
erreur `policy denied`, la politique a changé (ou votre binding
de compte). Contactez votre opérateur d'AC. Le service
[Exploitation](/fr/services/support/) est le chemin d'escalade
si votre opérateur d'AC c'est nous.