Le protocole ACME (Automatic Certificate Management Environment), principalement connu grâce à Let’s Encrypt, a démocratisé HTTPS en rendant l’obtention et le renouvellement des certificats SSL/TLS gratuits et automatisés pour les serveurs web. Cependant, la puissance d’ACME ne se limite pas à Apache ou Nginx. Tout service réseau communiquant via TLS peut bénéficier de certificats obtenus par ACME pour chiffrer ses communications. Cet article explore comment sécuriser des services cruciaux comme les serveurs de messagerie et les VPN.

Pourquoi Sécuriser les Services Non-Web avec TLS ?

Tout comme pour les sites web, la sécurisation des autres services réseau avec TLS est fondamentale pour plusieurs raisons :

1. Confidentialité : Chiffrer les données en transit pour empêcher l’écoute clandestine. Ceci est vital pour :
   • Les e-mails (contenu, identifiants de connexion via SMTP/IMAP/POP3).
   • Le trafic VPN (toutes les données passant par le tunnel).
   • Les connexions aux bases de données, les sessions FTP (FTPS), etc.
2. Authentification du serveur : Permettre aux clients de vérifier qu’ils se connectent au serveur légitime et non à un imposteur (prévention des attaques Man-in-the-Middle - MITM).
3. Intégrité des données : S’assurer que les données n’ont pas été altérées pendant la transmission.

Utiliser STARTTLS pour SMTP, et des connexions TLS dédiées pour IMAP/POP3 ou OpenVPN, est devenu une pratique standard pour garantir la sécurité de ces services.

Principes Généraux de l’Utilisation d’ACME pour les Services Non-Web

Sécuriser un service non-HTTP avec un certificat ACME implique deux étapes principales, similaires à la sécurisation d’un site web, mais avec des spécificités au niveau du déploiement :

1. Obtention du Certificat :

   • Validation de domaine : Le processus reste identique. Vous devez prouver le contrôle du nom de domaine pour lequel le certificat sera émis (ex: mail.example.com, vpn.example.com). Les défis courants sont :
     • HTTP-01 : Nécessite qu’un serveur web écoute sur le port 80 du domaine à valider. Si le service non-web est sur une machine différente ou ne peut pas servir de contenu web, vous pouvez utiliser un serveur web temporaire sur une machine accessible ou utiliser un client ACME en mode “standalone” qui lance son propre serveur web temporaire (si le port 80 est disponible).
     • DNS-01 : Plus flexible et souvent préféré pour les services non-HTTP. Il ne requiert pas d’accès au serveur du service lui-même pour la validation, seulement la capacité de modifier les enregistrements DNS du domaine via une API. C’est la méthode requise pour les certificats wildcard.
   • Nom du certificat : Le nom commun (CN) ou un nom alternatif du sujet (SAN) dans le certificat doit correspondre exactement au nom d’hôte que les clients utiliseront pour se connecter au service (ex: mail.example.com).

2. Déploiement et Configuration du Certificat :

   • C’est ici que la configuration diffère grandement d’un service à l’autre. Chaque service (Postfix, Dovecot, OpenVPN, etc.) a ses propres directives de configuration pour spécifier :
     • Le chemin vers la clé privée (privkey.pem).
     • Le chemin vers le certificat du serveur (cert.pem ou fullchain.pem).
     • Souvent, le chemin vers le certificat de l’autorité de certification intermédiaire (chain.pem).
   • Redémarrage/Rechargement du service : Après chaque renouvellement et copie des nouveaux fichiers de certificat, le service concerné doit être redémarré ou sa configuration rechargée pour qu’il utilise le nouveau certificat.

Utiliser un Client ACME (Exemples avec acme.sh et Certbot)

Des clients ACME comme acme.sh (très flexible avec ses “deploy hooks”) ou Certbot (avec son option --deploy-hook) sont bien adaptés pour ces tâches.

Étape 1 : Obtention du Certificat

Choisissez un client ACME et la méthode de validation.

Exemple avec acme.sh et le défi DNS-01 (recommandé pour les services non-HTTP) : Supposons que vous vouliez un certificat pour mail.example.com et que votre fournisseur DNS soit Cloudflare.

1. Configurez les variables d’environnement pour l’API de votre fournisseur DNS (voir la documentation d’acme.sh pour DNS API). Pour Cloudflare :

export CF_Token="VOTRE_TOKEN_API_CLOUDFLARE"
# export CF_Account_ID="VOTRE_ID_DE_COMPTE_CLOUDFLARE" # Peut être nécessaire

2. Émettez le certificat :

acme.sh --issue --dns dns_cf -d mail.example.com --server letsencrypt

Remplacez dns_cf par l’identifiant de votre fournisseur DNS.

Exemple avec Certbot et le défi HTTP-01 (si un serveur web est disponible) : Si un serveur web écoute sur mail.example.com sur le port 80 :

sudo certbot certonly --webroot -w /var/www/html/mail_validation_dir -d mail.example.com

Ou en mode standalone (Certbot lancera un serveur web temporaire) :

sudo certbot certonly --standalone -d mail.example.com

Étape 2 : Déploiement et Automatisation avec les “Deploy Hooks”

Une fois le certificat obtenu (et à chaque renouvellement), il doit être copié aux emplacements attendus par vos services, et les services doivent être rechargés.

acme.sh utilise la commande --install-cert ou des scripts de déploiement personnalisés (--deploy-hook). Certbot utilise l’option --deploy-hook /chemin/vers/votre/script.sh. Le script recevra des variables d’environnement comme $RENEWED_LINEAGE et $RENEWED_DOMAINS.

Exemples de Configuration et de Déploiement

A. Serveur Mail :

Postfix (SMTP) et Dovecot (IMAP/POP3) Supposons que nous utilisons mail.example.com pour SMTP, IMAP et POP3. Le certificat a été obtenu pour mail.example.com.

Chemins des certificats avec acme.sh :

• Clé privée : ~/.acme.sh/mail.example.com/mail.example.com.key
• Certificat complet (serveur + intermédiaire) : ~/.acme.sh/mail.example.com/fullchain.cer
• Certificat serveur seul : ~/.acme.sh/mail.example.com/mail.example.com.cer
• Certificat intermédiaire : ~/.acme.sh/mail.example.com/ca.cer

1. Configuration de Postfix (/etc/postfix/main.cf) :

smtpd_tls_cert_file = /etc/postfix/ssl/mail.example.com.fullchain.pem
smtpd_tls_key_file = /etc/postfix/ssl/mail.example.com.key.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtp_tls_security_level = may # Pour les connexions sortantes
smtp_tls_loglevel = 1

# Optionnel : pour les versions plus anciennes qui ne gèrent pas bien fullchain.pem
# smtpd_tls_CAfile = /etc/postfix/ssl/mail.example.com.chain.pem

2. Configuration de Dovecot (/etc/dovecot/conf.d/10-ssl.conf) :

ssl = required
ssl_cert = </etc/dovecot/ssl/mail.example.com.fullchain.pem
ssl_key = </etc/dovecot/ssl/mail.example.com.key.pem

# Optionnel : pour les versions plus anciennes
# ssl_ca = </etc/dovecot/ssl/mail.example.com.chain.pem

Assurez-vous que les permissions des clés privées sont restrictives (chmod 600).

3. Script de déploiement (exemple de hook pour acme.sh ou Certbot) :

Créez un script deploy_mail_certs.sh :

#!/bin/bash

DOMAIN="mail.example.com" # Ou récupéré des variables d'environnement du hook

# Chemins des certificats sources (ajuster si vous utilisez Certbot)
# Pour acme.sh, les chemins sont généralement passés en arguments au script de hook.
# Cet exemple suppose que les fichiers sont déjà au bon endroit via --install-cert
# ou que le script est appelé avec les chemins corrects.

POSTFIX_SSL_DIR="/etc/postfix/ssl"
DOVECOT_SSL_DIR="/etc/dovecot/ssl"
ACME_CERT_DIR="/home/user/.acme.sh/<span class="math-inline">\{DOMAIN\}\_ecc" \# Ajuster selon la conf acme\.sh
KEY\_FILE\="</span>{ACME_CERT_DIR}/<span class="math-inline">\{DOMAIN\}\.key"
FULLCHAIN\_FILE\="</span>{ACME_CERT_DIR}/fullchain.cer"

# Créer les répertoires si nécessaire
mkdir -p "$POSTFIX_SSL_DIR"
mkdir -p "$DOVECOT_SSL_DIR"

# Copier les certificats pour Postfix
cp "$KEY_FILE" "<span class="math-inline">POSTFIX\_SSL\_DIR/</span>{DOMAIN}.key.pem"
cp "$FULLCHAIN_FILE" "<span class="math-inline">POSTFIX\_SSL\_DIR/</span>{DOMAIN}.fullchain.pem"
chmod 600 "<span class="math-inline">POSTFIX\_SSL\_DIR/</span>{DOMAIN}.key.pem"

# Copier les certificats pour Dovecot
cp "$KEY_FILE" "<span class="math-inline">DOVECOT\_SSL\_DIR/</span>{DOMAIN}.key.pem"
cp "$FULLCHAIN_FILE" "<span class="math-inline">DOVECOT\_SSL\_DIR/</span>{DOMAIN}.fullchain.pem"
chmod 600 "<span class="math-inline">DOVECOT\_SSL\_DIR/</span>{DOMAIN}.key.pem"

echo "Certificats déployés pour Postfix et Dovecot."

# Recharger les services
echo "Rechargement de Postfix..."
if systemctl is-active --quiet postfix; then
    systemctl reload postfix
else
    echo "Postfix n'est pas actif."
fi

echo "Rechargement de Dovecot..."
if systemctl is-active --quiet dovecot; then
    systemctl reload dovecot
else
    echo "Dovecot n'est pas actif."
fi

echo "Déploiement terminé."
exit 0 # Important pour acme.sh, signifie succès

Rendez-le exécutable (chmod +x deploy_mail_certs.sh).

Avec acme.sh --install-cert (plus simple pour des cas comme celui-ci) :

acme.sh --install-cert -d mail.example.com \
    --key-file       /etc/postfix/ssl/mail.example.com.key.pem \
    --fullchain-file /etc/postfix/ssl/mail.example.com.fullchain.pem \
    --reloadcmd     "systemctl reload postfix"

# Répéter pour Dovecot si les chemins sont différents ou créer des liens symboliques
# Ou utiliser un script de hook plus complexe si les fichiers doivent être dupliqués.
# Pour des fichiers partagés (si Postfix et Dovecot peuvent lire les mêmes fichiers) :
acme.sh --install-cert -d mail.example.com \
    --key-file       /etc/ssl/private/mail.example.com.key \
    --fullchain-file /etc/ssl/certs/mail.example.com.fullchain.pem \
    --reloadcmd     "systemctl reload postfix && systemctl reload dovecot"

Puis configurer Postfix et Dovecot pour utiliser ces chemins partagés.

B. Serveur VPN : OpenVPN

Supposons que nous utilisons vpn.example.com.

1. Configuration d’OpenVPN (/etc/openvpn/server/server.conf ou similaire) :

OpenVPN utilise typiquement trois fichiers :

• ca : Le certificat de l’autorité de certification intermédiaire (pour Let’s Encrypt, c’est chain.pem ou ca.cer).
• cert : Le certificat du serveur seul (cert.pem ou vpn.example.com.cer).
• key : La clé privée du serveur (privkey.pem ou vpn.example.com.key).

port 1194
proto udp
dev tun

ca /etc/openvpn/ssl/ca.pem
cert /etc/openvpn/ssl/vpn.example.com.crt
key /etc/openvpn/ssl/vpn.example.com.key  # Ceci doit être gardé secret

dh /etc/openvpn/ssl/dh.pem # Paramètres Diffie-Hellman

# ... autres configurations OpenVPN

2. Déploiement avec acme.sh –install-cert :

VPN_CERT_DIR="/etc/openvpn/ssl"
DOMAIN_NAME="vpn.example.com"
SERVICE_NAME="openvpn-server@server.service" # Ajuster si nécessaire

acme.sh --install-cert -d ${DOMAIN_NAME} \
    --key-file       <span class="math-inline">\{VPN\_CERT\_DIR\}/</span>{DOMAIN_NAME}.key \
    --cert-file      <span class="math-inline">\{VPN\_CERT\_DIR\}/</span>{DOMAIN_NAME}.crt \
    --ca-file        ${VPN_CERT_DIR}/ca.pem \
    --reloadcmd     "systemctl restart ${SERVICE_NAME}"

Assurez-vous que le fichier de clé privée (${VPN_CERT_DIR}/${DOMAIN_NAME}.key) a des permissions restrictives (chmod 600). OpenVPN nécessite souvent un redémarrage plutôt qu’un simple rechargement.

Considérations Importantes

Permissions des Fichiers : Les clés privées doivent impérativement être protégées en lecture (chmod 600) et accessibles uniquement par root ou l’utilisateur sous lequel tourne le service. Atomicité : Lors du remplacement des fichiers de certificat, assurez-vous que le service ne se retrouve pas temporairement avec un ensemble incohérent de clé/certificat. La plupart des commandes de rechargement de service sont conçues pour gérer cela. Tests : Testez rigoureusement vos scripts de déploiement. Vous pouvez forcer un renouvellement avec acme.sh –renew -d votre.domaine.com –force ou sudo certbot renew –force-renewal. Nommage Cohérent (FQDN) : Les clients des services (clients mail, clients VPN) doivent être configurés pour utiliser le nom d’hôte exact (FQDN) présent dans le certificat. Sauvegardes : Bien que les certificats ACME soient facilement remplaçables, avoir une sauvegarde de votre configuration ACME (ex: ~/.acme.sh/ ou /etc/letsencrypt/) est une bonne pratique.

Conclusion

ACME est un outil incroyablement polyvalent qui simplifie grandement la sécurisation de pratiquement n’importe quel service utilisant TLS, et pas seulement les serveurs web. En comprenant les principes de base de l’obtention et du déploiement des certificats, et en utilisant les fonctionnalités de hook de clients comme acme.sh ou Certbot, vous pouvez automatiser la gestion des certificats pour vos serveurs mail, VPN, et bien d’autres services. L’effort initial de configuration est largement compensé par les gains en sécurité et la tranquillité d’esprit apportée par une infrastructure entièrement chiffrée et automatiquement maintenue.