Le certificat TLS/SSL est utilisé pour vérifier l’authenticité des serveurs (surtout les sites Web) et chiffrer les données échangées entre les utilisateurs et les sites Web. Ils garantissent l’intégrité des données et préviennent l’espionnage. La numérisation des entreprises et du monde en général, ainsi que l’obligation des navigateurs d’utiliser le protocole HTTPS:// par défaut, ont augmenté considérablement la demande de certificats.
Pour répondre à cette demande croissante, de plus en plus d’entreprises envisagent d’utiliser un certificat wildcard (*.nomdedomaine.com). Bien qu’il présente des avantages en termes de réduction des coûts et de flexibilité, il est important de connaître également les inconvénients de ce type de certificat. Faisons un tour d’horizon du certificat wildcard.
Qu’est-ce qu’un certificat wildcard ?
Un certificat TLS standard sécurise un nom d’hôte (CN pour Common Name ou FQDN pour Fully Qualified Domain Name) précisément défini dans ses métadonnées. Par exemple, Google possède un certificat pour mail.google.com.
- Ce certificat est valable uniquement pour : https://mail.google.com/
- Il ne peut pas être utilisé pour : https://google.com/ – https://images.google.com/ – https://my.mail.google.com/
En d’autres termes, le nom d’hôte doit correspondre exactement. Si vous essayez d’utiliser ce certificat sur https://my.mail.google.com/, votre navigateur affichera une erreur de certificat.
Un certificat TLS wildcard, en revanche, est différent. Comme son nom l’indique, il utilise une correspondance générique plutôt qu’une correspondance exacte. Cette correspondance générique est indiquée par “” dans le CN et couvre tous les sous-domaines du même niveau. Par exemple, le certificat .google.com.
- Ce certificat est valable pour : https://mail.google.com/ ET https://images.google.com/ ainsi que tous les sous-domaines possibles de google.com.
- Il ne peut pas être utilisé pour : https://google.com/ (sans sous-domaine) ou https://my.mail.google.com/ (niveau de sous-domaine différent).
Les avantages pratiques du certificat wildcard
Dans certaines situations, le certificat wildcard est très pratique. Par exemple, un hébergeur proposant des sites Web pour différents clients, hébergés sur un serveur mutualisé et accessibles via différents sous-domaines tels que client1.monsite.com, client2.monsite.com, client3… Il est peu pratique, techniquement complexe et plus coûteux de demander un nouveau certificat pour chaque client. L’option la plus simple est d’utiliser un certificat wildcard pour .monsite.com, qui couvrira tous les clients. La même logique s’applique à une entreprise souhaitant accéder à ses sites Web via des FQDN dérivés d’un même domaine et hébergés sur un même serveur web, .monentreprise.com.
Mais quels sont les risques ?
Dans les cas mentionnés ci-dessus, tous les sites sont hébergés sur un seul serveur. Cependant, pour les grandes entreprises ou les sites Web importants, les hébergements sont souvent plus complexes et se trouvent sur des serveurs différents. Reprenons notre exemple avec Google : images.google.com et mail.google.com. Ces deux applications sont liées à des services différents de l’entreprise, hébergés sur des serveurs différents et gérées par des équipes techniques différentes. Ce type d’organisation est fréquent dans les grandes entreprises. Malheureusement, la sécurité des certificats wildcard s’arrête ici.
Le problème avec les certificats wildcard, et dans une moindre mesure les certificats contenant des entrées multiples (les fameux SAN, Subject Alternative Names), est qu’ils doivent être déployés sur plusieurs serveurs. En effet, pour assurer la sécurité d’un certificat TLS/SSL, il est essentiel de protéger la clé privée associée. Idéalement, celle-ci doit être stockée en sécurité. Lorsqu’un certificat est installé sur plusieurs serveurs, les clés privées correspondantes se déplacent, augmentant ainsi le risque de compromission.
Le cas de la compromission d’un certificat
En cas de compromission d’un certificat, ou en cas d’erreur sur celui-ci (problème de renouvellement), il est essentiel d’intervenir rapidement pour limiter les dommages. Cela implique d’obtenir un nouveau certificat (ou renouveler l’ancien), d’installer le nouveau certificat et, si nécessaire, de révoquer le certificat compromis.
Dans notre exemple de création de sites Web sur un seul serveur, ce n’est pas un problème. Nous avons un seul serveur qui a été compromis, le certificat volé/expiré/compromis ne fonctionne que sur ce serveur spécifique. Nous avons donc limité les dommages autant que possible.
Cependant, dans un scénario avec plusieurs serveurs, si le certificat d’un seul serveur est compromis, tous les serveurs sont affectés. Cela entraîne des conséquences sur l’ensemble des serveurs et nécessite une intervention plus large, souvent en urgence, pour réparer les dégâts. Il est important de noter que le certificat circule souvent entre plusieurs équipes et peut être installé sur de nombreux serveurs sans être répertorié. Les conséquences peuvent être considérables.
Revenons à notre exemple avec Google. Supposons que seul le serveur images.google.com ait été piraté et que mail.google.com n’ait pas été affecté. Étant donné que le certificat pour images.google.com est un certificat wildcard pour *.google.com, le pirate informatique qui a compromis le service d’images peut également usurper l’identité du serveur mail.google.com et intercepter le trafic du service de messagerie, même si ce serveur n’a jamais été piraté.
Bonne pratique à suivre : un certificat TLS/SSL par serveur…
Dans notre dernier exemple, si nous avions utilisé deux certificats au lieu d’un seul, chaque serveur aurait eu accès à son propre certificat, limitant ainsi le risque. Dans un monde idéal, chaque certificat ne devrait être utilisé que pour un seul serveur (ou pour un groupe homogène de serveurs). Différents services sur différents serveurs doivent avoir leurs propres certificats, généralement non wildcard.
Un certificat wildcard peut être utilisé si vous avez de nombreux noms d’hôte, tels que des sous-domaines, pointant vers le même service sur le même serveur. Cependant, veillez à ce que ce certificat générique ne couvre pas les noms d’hôte pointant vers d’autres serveurs. Dans ce cas, chaque service devrait avoir ses propres certificats.
Enfin, si vous avez quelques noms d’hôte pointant vers des serveurs uniques et que tout le reste est sur un même service, il est préférable de choisir des certificats distincts. Par exemple, vous pouvez utiliser un certificat pour login.monsite.com et un certificat wildcard pour *.clients.monsite.com. Dans ce dernier cas, si le nombre de clients est fixe ou clairement défini, il est préférable d’opter pour un certificat avec une liste précise de SAN, afin de mieux contrôler les noms d’hôte sécurisés et d’éviter d’utiliser le protocole HTTPS:// sur des noms d’hôte inconnus.
Conclusion
Bien que l’option du certificat wildcard soit disponible et puisse être utile dans certains cas très spécifiques, en réalité, il ne devrait jamais être nécessaire de l’utiliser, tout comme il ne devrait jamais être nécessaire d’installer le même certificat sur différents serveurs non liés en cluster.
