Depuis une décennie, le chiffrement Web repose sur une idée simple : les certificats TLS sont émis pour des noms de domaine, et non pour des adresses IP. Cependant, cette frontière entre « ce que l’utilisateur écrit » (un domaine) et « ce qui route réellement Internet » (une adresse IP) commence à s’estomper. Let’s Encrypt permet désormais d’émettre des certificats valides pour IPv4 et IPv6. Ce changement ouvre la voie à la sécurisation des services sans dépendre du DNS et pousse le secteur vers un modèle de confiance plus dynamique, basé sur l’automatisation et des renouvellements fréquents.
Pourquoi cela est-il important : lorsque le service fonctionne « directement » sur une IP
Let’s Encrypt reconnaît que la majorité de ses abonnés continuera d’utiliser des certificats pour des noms de domaine — c’est la norme : les utilisateurs identifient les services par leur nom, pas par leur adresse IP. Mais la société admet aussi qu’il existe des cas où l’IP est l’identifiant pratique ou, tout simplement, le seul disponible. Parmi les scénarios mis en avant par l’organisation :
- Accès à un service sans domaine, avec une fiabilité et une commodité moindres comparé au DNS.
- Pages d’accueil des fournisseurs d’hébergement, lorsque quelqu’un saisit une IP dans le navigateur et tombe aujourd’hui sur une alerte de sécurité.
- Services d’infrastructure, comme DNS over HTTPS (DoH), où un certificat reconnu officiellement facilite la vérification de l’identité et le renforcement des politiques sur le client.
- Accès à distance à des dispositifs domestiques (NAS, IoT) dépourvus de nom de domaine.
- Connexions éphémères dans les infrastructures cloud, telles que des liaisons entre services backend ou la gestion temporaire de serveurs, à condition que l’adresse IP publique soit disponible.
Concrètement, cette évolution offre une solution « propre » pour les laboratoires, environnements temporaires, tests de concept ou déploiements qui, par conception, ne souhaitent pas dépendre du DNS pour activer HTTPS.
La condition essentielle : des certificats d’une durée extrêmement courte
La contrepartie est significative. Let’s Encrypt annonce que les certificats intégrant une adresse IP doivent être « à courte durée de vie » : une validité de 160 heures (un peu plus de six jours). Ce plafond n’est pas anodin : il impose que tout le processus soit automatisé dès le départ.
De plus, l’organisation a rendu généralisée (en production) cette option pour les certificats IP ainsi que pour ceux de 6 jours pour les noms de domaine, confirmant que l’avenir du TLS passe par des renouvellements rapides, une exposition au risque limitée, et une moindre dépendance à des certificats « longue durée ».
Que cela implique-t-il opérationnellement ?
Pour émettre des certificats « à courte durée » intégrant une IP, le client ACME doit supporter les Profiles ACME et demander le profil approprié (habituellement, shortlived). En clair : avoir Certbot ne suffit pas; il faut aussi vérifier que le client et sa configuration supportent ces profils.
Une autre restriction cruciale : le protocole DNS-01 ne peut pas être utilisé pour prouver la maîtrise d’une IP. Let’s Encrypt limite la validation aux méthodes HTTP-01 et TLS-ALPN-01. C’est logique : le DNS sert à démontrer le contrôle d’un nom, pas d’un numérique.
Le contexte global : de 90 à 45 jours (et le rôle de l’automatisation)
Cela s’inscrit dans une stratégie que Let’s Encrypt porte depuis un certain temps : un monde où la durée de validité par défaut diminue. La CA a expliqué son projet d’évoluer, d’un standard actuel de 90 jours vers 45 jours, conformément à la tendance du secteur. La feuille de route évoque l’objectif 2028 pour une transition complète, tout en lançant des initiatives pour simplifier les renouvellements automatiques (améliorations telles que ARI dans l’écosystème ACME, par exemple).
En résumé : si auparavant la sécurité reposait sur « émettre puis oublier », le nouveau modèle privilégie « émettre, renouveler et vérifier en continu ». Les certificats IP — par leur nature changeante et le risque de réaffectation — représentent l’exemple extrême de cette philosophie.
Tableau récapitulatif pour mieux comprendre
| Type de certificat | Identifiant | Durée typique | Validation supportée | Implication pratique |
|---|---|---|---|---|
| TLS standard | Nom de domaine | 90 jours | HTTP-01 / DNS-01 / TLS-ALPN-01 (selon le cas) | Renouvellement périodique, automatisable |
| Futur du TLS (feuille de route) | Nom de domaine | 45 jours | Même que standard (selon CA/client) | Plus d’automatisation, moins de risque lié à l’exposition |
| TLS à courte durée | Nom de domaine | 160 heures | Selon le client/le profil | Renouvellement très fréquent, adapté à une automatisation avancée |
| TLS pour IP (Let’s Encrypt) | IPv4/IPv6 | 160 heures (obligatoire) | HTTP-01 / TLS-ALPN-01 | Idéal pour labs / infra ; nécessite automatisation et contrôle de l’endpoint |
(Les profils et exigences dépendent du support du client ACME et de la configuration du profil demandé.)
Impact concret : plus de sécurité, mais moins de tolérance à l’improvisation
Du point de vue de la sécurité, cet audiovisuel est clair : avec des certificats très courts, en cas de fuite de clé ou erreur de délivrance, la période d’impact est considérablement réduite. Mais du côté opérationnel, le message est également net : toute mise en œuvre sans automatisation — renouvellement, redémarrage des services, surveillance du processus — risque d’engendrer des interruptions évitables.
Cependant, pour un secteur en plein essor du self-hosting, des labs et des infrastructures éphémères, cette démarche est cohérente : HTTPS ne se limite plus à « un domaine », mais devient « un contrôle vérifiable de l’endpoint », même si celui-ci est une IP.
Questions fréquentes
À quoi sert un certificat TLS pour une adresse IP ?
Il permet d’activer HTTPS lorsque l’accès se fait directement via IPv4 ou IPv6 (sans domaine), ou pour sécuriser un point d’accès d’infrastructure où le nom de domaine n’est pas pratique.
Pourquoi Let’s Encrypt limite ces certificats à 160 heures ?
Parce que les IP peuvent changer ou être réattribuées facilement. Une durée très courte minimise le risque que le certificat reste actif quand l’IP n’est plus sous votre contrôle, tout en limitant l’impact d’une fuite de clé.
Est-il possible de valider un certificat IP via DNS-01 ?
Non. Let’s Encrypt précise que pour les IP, seules les méthodes HTTP-01 et TLS-ALPN-01 sont supportées, étant donné que DNS-01 vérifie le contrôle d’un nom de domaine, pas d’une adresse numérique.
Que faut-il pour déployer cela en production sans souci ?
Un client ACME supportant les Profiles ACME, une automatisation du renouvellement (via cron/systemd), une relance automatique du service (Nginx/Apache/HAProxy, etc.), et une surveillance du processus d’émission/renouvellement.
