Comment gérer AutoSSL pour une sécurité optimale du site Web
AutoSSL est une fonctionnalité cPanel qui provisionne et renouvelle automatiquement les certificats SSL/TLS pour tous les domaines d’un compte d’hébergement, en utilisant une autorité de certification de confiance telle que Let's Encrypt ou Sectigo, sans nécessiter d’intervention manuelle. Lorsqu’un certificat approche de son expiration, AutoSSL le réémet silencieusement, maintenant un HTTPS ininterrompu sur chaque domaine et sous-domaine qu’il gère.
Pour tout administrateur de serveur gérant des sites sur un VPS avec cPanel, AutoSSL élimine la cause la plus courante des défaillances HTTPS inattendues : les renouvellements manuels oubliés. Ce guide couvre l’intégralité du cycle de vie opérationnel — activation, configuration, dépannage et renforcement d’AutoSSL — avec la profondeur technique nécessaire pour le gérer de manière fiable en production.
Ce que fait réellement AutoSSL en coulisses
AutoSSL n’est pas simplement une tâche cron qui appelle Certbot. C’est un sous-système natif de cPanel avec sa propre architecture de plugins de fournisseurs. Lorsqu’il est déclenché, il effectue la séquence suivante :
- Découverte des domaines — analyse tous les domaines, sous-domaines et noms d’hôtes de messagerie associés au compte cPanel.
- Analyse des lacunes de certificats — compare les certificats existants avec la liste complète des domaines et identifie tout nom d’hôte non couvert par un certificat valide et de confiance.
- DCV (Validation du contrôle de domaine) — prouve la propriété du domaine en utilisant l’une des deux méthodes : validation par fichier HTTP (en plaçant un jeton à
/.well-known/pki-validation/) ou validation DNS via un enregistrementTXT. - Émission du certificat — demande un nouveau certificat auprès de l’autorité de certification configurée (Let's Encrypt par défaut sur la plupart des hébergeurs, Sectigo sur les serveurs sous licence WHM avec un accord Sectigo).
- Installation — installe le certificat dans la configuration de l’hôte virtuel Apache ou LiteSpeed et met à jour le magasin de certificats cPanel.
- Planification du renouvellement — AutoSSL s’exécute selon un calendrier cron à l’échelle du serveur (généralement toutes les 24 heures) et commence les tentatives de renouvellement lorsqu’un certificat a moins de 15 jours restants.
Comprendre ce pipeline est essentiel pour diagnostiquer les défaillances, car un problème à n’importe quelle étape produit une classe d’erreur différente.
AutoSSL vs. Certificats manuels vs. Certbot : une comparaison directe
| Fonctionnalité | AutoSSL (cPanel) | Certbot (autonome) | Certificat payant/manuel |
|---|---|---|---|
| — | — | — | — |
| Coût | Gratuit (Let's Encrypt / Sectigo DV) | Gratuit (Let's Encrypt) | $10–$1,000+/an |
| Automatisation du renouvellement | Entièrement automatique via cron cPanel | Nécessite un minuteur systemd ou une configuration cron | Manuel ou via le portail de l’autorité de certification |
| Prise en charge des certificats wildcard | Non (DV SAN uniquement) | Oui (avec défi DNS) | Oui (OV/EV/Wildcard) |
| Validation EV/OV | Non | Non | Oui |
| Intégration cPanel | Native | Externe, nécessite des modifications manuelles de vhost | Via le gestionnaire SSL cPanel |
| SAN multi-domaines | Oui (domaines par compte) | Oui | Oui |
| Méthode DCV | Fichier HTTP ou DNS TXT | HTTP, DNS, TLS-ALPN | E-mail, HTTP, DNS |
| Visibilité des défaillances | Journaux WHM/cPanel + alertes e-mail | Sortie CLI + journal systemd | Tableau de bord de l’autorité de certification |
| Adapté à la production | Oui (cas d’utilisation DV) | Oui (tout cas d’utilisation) | Oui (cas d’utilisation à haute assurance) |
Pour la grande majorité des sites web fonctionnant dans un environnement partagé ou VPS, AutoSSL couvre toutes les exigences. Certbot est préférable lorsque vous avez besoin de certificats wildcard ou que vous opérez en dehors d’un environnement cPanel. Les certificats payants restent nécessaires uniquement pour les exigences de validation OV/EV, comme les institutions financières ou les mandats de conformité d’entreprise.
Prérequis avant d’activer AutoSSL
Avant d’exécuter AutoSSL, vérifiez que les conditions suivantes sont remplies. Ignorer cette liste de contrôle est la principale raison pour laquelle les configurations initiales échouent.
Résolution DNS
- Chaque domaine et sous-domaine que vous souhaitez couvrir doit résoudre vers l’adresse IP du serveur. Le DCV HTTP d’AutoSSL échouera si un domaine pointe ailleurs.
- Vérifiez avec :
dig +short yourdomain.com A
Accessibilité du serveur web
- Le port 80 doit être ouvert et servir du contenu. Le défi HTTP de Let's Encrypt nécessite une réponse HTTP non authentifiée sur le port 80, même si vous redirigez ensuite tout vers HTTPS.
- Vérifiez :
curl -I http://yourdomain.com/.well-known/pki-validation/
Aucun certificat tiers conflictuel
- Si un domaine possède déjà un certificat installé manuellement qui n’est pas expiré, AutoSSL ne le remplacera pas, sauf si vous l’excluez ou le supprimez explicitement.
Fournisseur AutoSSL WHM configuré (administrateurs de serveur)
- Dans WHM, accédez à SSL/TLS > Gérer AutoSSL et confirmez qu’un fournisseur est sélectionné et actif. Sur l’hébergement VPS AlexHost avec cPanel, Let's Encrypt est généralement préconfiguré.
Comment activer AutoSSL dans cPanel : étape par étape
Étape 1 : Accéder à l’interface de statut SSL/TLS
Connectez-vous à votre compte cPanel. Dans la section Sécurité, cliquez sur Statut SSL/TLS. Ce tableau de bord affiche chaque domaine et sous-domaine du compte, avec un code couleur selon l’état du certificat :
- Cadenas vert — certificat valide installé
- Avertissement jaune — certificat présent mais expirant bientôt ou utilisant une autorité de certification auto-signée/non fiable
- X rouge — aucun certificat valide
Étape 2 : Sélectionner les domaines pour la couverture AutoSSL
Examinez la liste des domaines. Par défaut, tous les domaines sont éligibles. Si vous souhaitez exclure des sous-domaines spécifiques (environnements de staging, outils internes ou domaines intentionnellement servis via HTTP), cochez leurs cases et cliquez sur Exclure d’AutoSSL. Les domaines exclus ne seront pas touchés par le processus AutoSSL.
Étape 3 : Exécuter AutoSSL
Cliquez sur le bouton Exécuter AutoSSL. cPanel commencera immédiatement le processus DCV et d’émission. Pour les comptes avec de nombreux domaines, cela peut prendre plusieurs minutes. L’interface se met à jour en temps réel, affichant le statut par domaine.
Vous pouvez également déclencher AutoSSL par programmation via l’API cPanel :
/usr/local/cpanel/bin/autossl_check --user=cpanelusernameOu depuis WHM pour tous les comptes sur le serveur :
/usr/local/cpanel/bin/autossl_check_all_usersÉtape 4 : Vérifier l’installation du certificat
Une fois AutoSSL terminé, revenez à Statut SSL/TLS et confirmez que tous les domaines ciblés affichent un cadenas vert. Vous pouvez également vérifier depuis la ligne de commande :
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates -issuerCela affiche la fenêtre de validité du certificat et l’autorité de certification émettrice, confirmant que le bon certificat est actif.
Configuration des notifications AutoSSL
Les défaillances AutoSSL sont silencieuses par défaut, sauf si vous configurez des alertes. Dans WHM, accédez à SSL/TLS > Gérer AutoSSL > Paramètres de notification et activez les alertes e-mail pour :
- Les échecs d’émission de certificats
- Les échecs DCV
- Les certificats expirant dans un délai configurable (recommandé : 20 jours)
Au niveau du compte cPanel, assurez-vous que l’adresse e-mail de contact sous Préférences > Informations de contact est à jour. Les événements AutoSSL sont enregistrés dans /var/cpanel/logs/autossl/ sur le serveur, avec un fichier journal par exécution, horodaté pour une corrélation facile.
Dépannage d’AutoSSL : causes profondes et corrections
Échecs de validation de domaine (DCV)
Les échecs DCV sont l’erreur AutoSSL la plus courante. L’entrée de journal indique généralement : DCV failed for domain "sub.example.com".
Causes profondes et résolutions :
- DNS non propagé — Si vous avez récemment pointé un domaine vers ce serveur, la propagation DNS peut être incomplète. Attendez jusqu’à 48 heures ou vérifiez avec
dig @8.8.8.8 yourdomain.com A. - Domaine derrière un proxy (Cloudflare, etc.) — Si le proxy Cloudflare (nuage orange) est actif, le DCV HTTP d’AutoSSL peut échouer car le fichier de défi est servi depuis la périphérie de Cloudflare, et non depuis l’origine. Désactivez temporairement le proxy (nuage gris) lors de l’émission, ou passez au DCV basé sur DNS si votre fournisseur le prend en charge.
.htaccessbloquant/.well-known/— Certaines configurations.htaccessWordPress ou renforcées en matière de sécurité bloquent l’accès aux répertoires cachés. Ajoutez l’exception suivante :
RewriteRule ^.well-known/ - [L]- Port 80 bloqué par le pare-feu — Confirmez que le port 80 est ouvert dans votre pare-feu (
iptables -L -n | grep 80ou via le gestionnaire de pare-feu CSF/WHM).
Avertissements de contenu mixte après l’activation HTTPS
Après qu’AutoSSL provisionne un certificat, les navigateurs peuvent toujours afficher un avertissement « Non sécurisé » ou un cadenas avec un triangle d’avertissement. Cela est causé par du contenu mixte — des ressources (images, scripts, feuilles de style, iframes) chargées via http:// sur une page HTTPS par ailleurs.
Correction pour WordPress :
Installez le plugin Really Simple SSL, qui réécrit les URL internes et définit la variable serveur HTTPS. Vous pouvez également ajouter ceci à wp-config.php :
define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
$_SERVER['HTTPS'] = 'on';
}Correction au niveau du serveur (Apache/LiteSpeed) :
Ajoutez une redirection globale HTTP vers HTTPS dans votre hôte virtuel ou .htaccess :
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Après avoir appliqué la redirection, utilisez un outil comme Why No Padlock ou les DevTools du navigateur (onglet Réseau, filtrer par schéma) pour identifier les ressources HTTP restantes.
Échecs de renouvellement de certificat
Si AutoSSL ne parvient pas à renouveler un certificat qui était précédemment valide, consultez le journal AutoSSL pour l’échec spécifique :
ls -lt /var/cpanel/logs/autossl/ | head -5
cat /var/cpanel/logs/autossl/LATEST_LOG_FILECauses courantes d’échec de renouvellement :
- DNS modifié — Le domaine pointe maintenant vers un serveur différent. AutoSSL sur l’ancien serveur ne peut plus effectuer le DCV HTTP.
- Limites de débit de Let's Encrypt — Let's Encrypt impose une limite de 5 certificats en double par semaine et par domaine. Si vous avez déclenché AutoSSL manuellement à plusieurs reprises lors de tests, vous pouvez atteindre cette limite. Vérifiez sur crt.sh les émissions récentes.
- Licence WHM expirée — Sur les serveurs utilisant Sectigo comme fournisseur AutoSSL, une licence WHM expirée bloquera les nouvelles émissions. Vérifiez l’état de la licence dans WHM sous Configuration du serveur > Gestionnaire de licences.
- Incompatibilité de version cPanel — Assurez-vous que cPanel est mis à jour. Exécutez
upcpdepuis le shell du serveur pour appliquer les mises à jour.
Persistance de certificats auto-signés ou non fiables
Si un domaine affiche un certificat auto-signé malgré l’exécution réussie d’AutoSSL, un certificat installé manuellement peut avoir la priorité. Dans cPanel, accédez à SSL/TLS > Gérer les sites SSL et supprimez tout certificat installé manuellement pour le domaine concerné, puis réexécutez AutoSSL.
Configuration avancée : AutoSSL avec les domaines wildcard
AutoSSL n’émet pas nativement de certificats wildcard (*.example.com). Si votre application nécessite un wildcard — par exemple, des sous-domaines générés dynamiquement pour une plateforme SaaS — vous avez deux options :
Option 1 : Utiliser Certbot avec le défi DNS
certbot certonly --dns-cloudflare
--dns-cloudflare-credentials ~/.secrets/cloudflare.ini
-d "*.example.com" -d "example.com"Installez ensuite le certificat résultant manuellement via l’interface Gérer les sites SSL de cPanel ou via l’API cPanel.
Option 2 : Acheter un certificat DV wildcard
Les certificats DV wildcard de fournisseurs comme Sectigo ou DigiCert sont disponibles à un coût raisonnable et peuvent être installés via la gestion des certificats SSL. C’est la voie la plus simple pour les utilisateurs non techniques qui ont besoin d’une couverture wildcard sans gérer Certbot.
Considérations relatives à AutoSSL et à l’hébergement de messagerie
AutoSSL sécurise également les noms d’hôtes liés à la messagerie : mail.yourdomain.com, smtp.yourdomain.com, imap.yourdomain.com et webmail.yourdomain.com. Ceux-ci sont automatiquement inclus dans la liste SAN (Subject Alternative Name) du certificat émis.
Si vous exécutez un hébergement de messagerie sur le même serveur, vérifiez que le nom d’hôte du serveur de votre client de messagerie correspond à l’un des SAN du certificat. Une incompatibilité entre le nom d’hôte configuré dans Outlook ou Thunderbird et la liste SAN du certificat produira des erreurs SSL dans les clients de messagerie, même si le site web lui-même affiche un cadenas valide.
Vérifiez la liste complète des SAN d’un certificat installé :
echo | openssl s_client -connect mail.yourdomain.com:993 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"Renforcement de la sécurité au-delà d’AutoSSL
AutoSSL gère le provisionnement des certificats, mais la seule présence d’un certificat ne constitue pas une configuration TLS renforcée. Après avoir activé AutoSSL, appliquez les étapes de renforcement suivantes.
Imposer TLS 1.2 et 1.3 uniquement
Dans WHM sous Configuration du service > Configuration Apache > Configuration globale, désactivez TLS 1.0 et 1.1. Pour LiteSpeed, accédez à Console WebAdmin > Écouteurs > SSL > Version du protocole.
Activer HSTS (HTTP Strict Transport Security)
Ajoutez l’en-tête suivant à votre hôte virtuel ou .htaccess après avoir confirmé que HTTPS est stable :
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"N’activez pas preload tant que vous n’êtes pas certain que tous les sous-domaines sont couverts par des certificats valides et que vous avez l’intention de maintenir HTTPS de façon permanente. Le préchargement HSTS est irréversible à court terme.
Désactiver les suites de chiffrement faibles
Dans la configuration Apache de WHM, définissez la directive SSLCipherSuite sur une liste de chiffrement moderne. Une base de référence sûre :
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384Tester votre configuration
Exécutez votre domaine via le test de serveur SSL Labs après avoir appliqué les modifications. Visez une note A ou A+. AutoSSL seul donne généralement une note B sur les configurations cPanel par défaut ; le renforcement des chiffrements et des protocoles ci-dessus la pousse à A+.
Meilleures pratiques pour la gestion d’AutoSSL en production
Maintenez cPanel et WHM à jour. L’intégration Let's Encrypt d’AutoSSL dépend du client ACME fourni avec cPanel. Les versions obsolètes peuvent échouer face aux modifications de l’API Let's Encrypt. Exécutez les mises à jour via WHM ou planifiez-les avec :
/scripts/upcp --forceMaintenez des enregistrements DNS précis. Tout changement DNS — migration de serveur de noms, changement d’IP, activation de CDN — peut interrompre le DCV. Avant de migrer un domaine vers un nouveau serveur ou CDN, planifiez la réémission AutoSSL dans le cadre de la liste de contrôle de migration.
Ne vous fiez pas uniquement aux journaux AutoSSL. Configurez une surveillance externe des certificats à l’aide d’outils comme certspotter, la surveillance SSL d’Uptime Robot, ou un cron personnalisé qui vous alerte si l’expiration d’un certificat tombe en dessous de 20 jours :
#!/bin/bash
DOMAIN="yourdomain.com"
EXPIRY=$(echo | openssl s_client -connect ${DOMAIN}:443 -servername ${DOMAIN} 2>/dev/null
| openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "${EXPIRY}" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt 20 ]; then
echo "WARNING: ${DOMAIN} certificate expires in ${DAYS_LEFT} days" | mail -s "SSL Alert" admin@yourdomain.com
fiUtilisez des certificats séparés pour les domaines à haute valeur. Pour les domaines gérant des paiements ou des données utilisateur sensibles, envisagez de compléter le certificat DV d’AutoSSL par un certificat OV ou EV payant installé manuellement. AutoSSL et les certificats gérés manuellement peuvent coexister sur le même serveur — AutoSSL ignore simplement les domaines qui ont déjà un certificat valide et de confiance installé.
Auditez périodiquement les domaines exclus. Les domaines exclus d’AutoSSL sont faciles à oublier. Planifiez une révision trimestrielle de la liste d’exclusion dans Statut SSL/TLS pour vous assurer que les domaines de staging ou de développement ne sont pas accidentellement mis en ligne sans couverture de certificat.
Matrice de décision : quand AutoSSL est et n’est pas suffisant
| Scénario | AutoSSL suffisant ? | Alternative recommandée |
|---|---|---|
| — | — | — |
| Site web d’entreprise standard | Oui | — |
| Blog WordPress ou e-commerce (WooCommerce) | Oui | — |
| SaaS avec de nombreux sous-domaines dynamiques | Non | Certbot wildcard + défi DNS |
| Institution financière nécessitant un certificat EV | Non | Certificat EV payant |
| Domaine interne/intranet (DNS non public) | Non | Autorité de certification privée ou auto-signé avec confiance interne |
| Couverture du nom d’hôte du serveur de messagerie | Oui | — |
| Domaine proxifié par CDN (proxy complet Cloudflare) | Partiel | Certificat d’origine Cloudflare ou mode Full (Strict) |
| Environnement multi-serveurs avec équilibrage de charge | Partiel | Gestion centralisée des certificats (ex. : cert-manager) |
Points techniques clés à retenir
- AutoSSL s’exécute selon un calendrier cron à l’échelle du serveur et vérifie tous les comptes quotidiennement ; des déclenchements manuels sont disponibles via WHM ou l’API cPanel pour une émission immédiate.
- Le DCV HTTP nécessite que le port 80 soit ouvert et que le chemin
/.well-known/pki-validation/soit accessible publiquement — c’est l’erreur de configuration la plus courante. - Le mode proxy orange-cloud de Cloudflare bloque le DCV HTTP ; passez en grey-cloud lors de l’émission initiale ou utilisez le DCV basé sur DNS.
- AutoSSL n’émet pas de certificats wildcard ; utilisez Certbot avec un plugin DNS ou un certificat wildcard acheté pour cette exigence.
- HSTS ne doit être activé qu’après confirmation qu’AutoSSL est stable sur tous les sous-domaines ; un déploiement HSTS prématuré avec un certificat incomplet peut bloquer l’accès des utilisateurs aux sous-domaines.
- La surveillance externe des certificats est indispensable en production — les alertes internes d’AutoSSL sont un complément, et non un remplacement, de la surveillance indépendante des expirations.
- Pour les serveurs nécessitant un contrôle plus granulaire de la configuration TLS, le provisionnement d’un serveur dédié donne un accès complet à la pile SSL du serveur web sans les contraintes d’un environnement partagé.
- Les panneaux de contrôle VPS autres que cPanel (Plesk, DirectAdmin, CyberPanel) ont leurs propres équivalents AutoSSL avec des chemins de configuration différents, mais les mêmes mécanismes sous-jacents du protocole ACME.
Foire aux questions
AutoSSL fonctionne-t-il si mon domaine est derrière Cloudflare ?
Uniquement si Cloudflare est en mode DNS uniquement (nuage gris). Lorsque le proxy orange-cloud est actif, Cloudflare intercepte les requêtes HTTP, empêchant Let's Encrypt d’atteindre le fichier de jeton DCV sur votre serveur d’origine. Désactivez temporairement le proxy lors de l’émission ou configurez le mode SSL de Cloudflare sur « Full (Strict) » et utilisez plutôt un certificat d’origine Cloudflare.
À quelle fréquence AutoSSL tente-t-il de renouveler les certificats ?
Le cron AutoSSL s’exécute toutes les 24 heures à l’échelle du serveur. Il commence les tentatives de renouvellement lorsqu’un certificat a 15 jours ou moins restants. Les certificats Let's Encrypt ont une période de validité de 90 jours, donc le renouvellement se produit généralement vers le 75e jour.
AutoSSL peut-il coexister avec un certificat SSL payant installé manuellement ?
Oui. AutoSSL ignore tout domaine qui possède déjà un certificat valide et de confiance installé. Si vous installez un certificat payant manuellement via le gestionnaire SSL de cPanel, AutoSSL ne le remplacera pas. Une fois le certificat payant expiré, AutoSSL interviendra et émettra un certificat Let's Encrypt lors de sa prochaine exécution planifiée, à condition que le domaine passe le DCV.
Pourquoi mon client de messagerie affiche-t-il une erreur SSL alors que le site web possède un certificat AutoSSL valide ?
Le client de messagerie se connecte à un nom d’hôte (ex. : mail.yourdomain.com) qui peut ne pas être inclus dans la liste SAN du certificat, ou un certificat différent est installé sur les ports de messagerie (993, 587, 465). Exécutez la commande openssl s_client contre le port de messagerie et vérifiez que la liste SAN correspond au nom d’hôte que votre client est configuré pour utiliser.
Que se passe-t-il si AutoSSL ne parvient pas à renouveler et que le certificat expire ?
Les navigateurs afficheront un avertissement pleine page « Votre connexion n’est pas privée », et la plupart des utilisateurs ne continueront pas. Les robots des moteurs de recherche peuvent également signaler le site. Si vous avez activé HSTS, le navigateur refusera de se connecter entièrement sans option de contournement. Surveillez l’expiration de manière proactive avec des outils externes et configurez les alertes e-mail WHM pour détecter les échecs de renouvellement avant qu’ils n’atteignent l’expiration.
