Qu’est-ce qu’un certificat auto-signé ?

Un certificat TLS/SSL auto-signé n’est pas signé par une autorité de certification (CA) publiquement reconnue, mais par le développeur ou la société responsable du site web. Comme ils ne sont pas signés par une CA publiquement reconnue, ils sont généralement considérés comme peu sûrs pour les applications et sites web publics.

Le rôle d’une CA publique est de garantir la validité des informations incluses dans un certificat, notamment la propriété et/ou le contrôle du ou des noms de domaine associés au certificat dans le cas de TLS/SSL. Par conséquent, l’utilisation de certificats auto-signés équivaut à l’utilisation d’informations d’identification qui n’ont pas été émises par une autorité valide.

L’expression certificats auto-signés » fait généralement référence aux certificats TLS/SSL qui ont été générés de manière autonome, sans aucun lien avec un certificat racine ou intermédiaire. Elle peut également s’appliquer à d’autres certificats X.509 de signature numérique tels que S/MIME, de signature de code et de signature de document.

La nature des certificats auto-signés implique que les informations figurant sur le certificat n’ont pas été vérifiées par une partie de confiance (une CA publique), et ces certificats déclencheront une alerte de sécurité : Les navigateurs Web et les systèmes d’exploitation détecteront et signaleront les certificats qui n’ont pas été signés par une CA publique de confiance, car ils représentent un risque pour la sécurité de leurs utilisateurs : Le certificat ne provient pas d’une partie de confiance, il pourrait donc être l’œuvre d’un attaquant déployant une attaque de type « man-in-the-middle ».

Ces affichages d’avertissement font fuir les utilisateurs, qui craignent que leurs données personnelles ou financières ne soient en danger en interagissant avec votre site.

Par conception, les certificats auto-signés - qu'ils soient destinés à TLS/SSL, S/MIME, à la signature de documents ou à la signature de codes - peuvent avoir n'importe quelle période de validité car ils ne sont soumis à aucune réglementation. Ils devront toutefois être renouvelés et redéployés avant leur expiration. Plus la période de validité est longue, plus le risque d’oublier l’existence du certificat et sa date d’expiration est grand.

Contrairement aux certificats auto-signés, les certificats TLS/SSL de confiance publique ne peuvent être émis pour une durée supérieure à 13 mois. Avant 2015, la période de validité maximale autorisée était de cinq ans, mais elle a été progressivement réduite à 1 an. Ceci s’applique aux certificats Extended Validation (EV) et Organization Validation (OV) TLS/SSL.

L’utilisation d’un certificat auto-signé signifie que l’on choisit de procéder sans le soutien d’une autorité de certification de confiance pour garantir la validité des détails du certificat. Par défaut, les certificats auto-signés ne seront jamais reconnus par les navigateurs web et les systèmes d’exploitation. Il appartient à chaque utilisateur de contourner l’avertissement de sécurité en approuvant manuellement chaque certificat auto-signé qu’il rencontre, sur chaque appareil qu’il utilise, au cas par cas. Les messages d’avertissement indiquent clairement que les certificats auto-signés peuvent représenter un risque pour la sécurité, de sorte que les utilisateurs sont peu enclins à les utiliser.

Les certificats TLS/SSL auto-signés sont signalés par les navigateurs, car ils ne sont pas émis par des autorités de certification fiables et il n’y a donc aucune garantie que le certificat est légitime. Le navigateur affiche un avertissement indiquant que le certificat du site n’est pas émis par une CA de confiance et que la sécurité de la connexion n’est donc pas garantie.

Les alertes de sécurité des navigateurs et des systèmes d’exploitation dissuaderont l’utilisateur final d’utiliser le site web ou l’application, car il ne se sent pas en sécurité. C’est pourquoi les certificats auto-signés sont généralement utilisés pour les environnements de test ou les réseaux internes à faible risque uniquement.

Les certificats TLS/SSL auto-signés sont sûrs dans un environnement de test, et vous pouvez les utiliser en attendant que vos certificats soient émis par une CA publique. Mais leur utilisation dans un environnement de production réduira considérablement le trafic vers votre site Web ou votre application et entraînera un manque de confiance de la part des utilisateurs.

Certaines organisations peuvent trouver intéressant d’utiliser des certificats TLS/SSL auto-signés puisqu’ils peuvent être générés gratuitement ; cependant, ce à quoi elles ne pensent pas souvent, ce sont les risques de confiance et la maintenance des certificats auto-signés. Leur renouvellement, en particulier, peut entraîner de nombreux coûts cachés.

Un certificat TLS/SSL auto-signé est signé avec sa propre clé privée et n’est pas enchaîné à une Root CA ou intermédiaire. Les certificats auto-signés sont créés, émis et signés par l’entreprise ou le développeur responsable de la maintenance du site Web qui doit être signé. Bien que cela puisse être un moyen de réduire les coûts des certificats pour les sites Web internes, ce n’est jamais une bonne idée pour les sites et applications publics.

Les clés privées compromises peuvent constituer une menace majeure pour l’infrastructure de l’organisation. Vous pouvez signaler les certificats compromis à leur autorité de certification émettrice, qui les révoquera immédiatement. Mais pour les certificats auto-signés, il n’y aura pas de mécanisme de révocation fiable.

En outre, les organisations ne surveillent pas toujours leurs certificats auto-signés, ce qui fait que les certificats expirés ou compromis passent inaperçus. Ces certificats compromis constituent des passerelles permettant aux acteurs malveillants d’accéder au réseau et de lancer des attaques de logiciels malveillants avancés et sophistiqués, des attaques de type « man-in-the-middle » (MITM), des attaques de phishing et des botnets.

Aucune garantie ni assistance technique

Les autorités de certification publiques offrent un soutien, une expertise et des outils de gestion pour leurs certificats. Mais pour les certificats auto-signés, il n’existe aucune assistance, aucune expertise ni aucun outil de gestion car ces certificats sont générés en interne. Vous avez besoin de ressources humaines et financières pour en garder le contrôle.

Manque de visibilité et de contrôle

Les organisations utilisent des milliers de certificats numériques, émis par des CA privées et publiques, et il est difficile de suivre chacun de ces certificats manuellement. Pour renforcer la cyberdéfense, il est essentiel de savoir combien de certificats il y a, qui les possède, où ils se trouvent et où sont stockées les clés privées.

Les organisations qui utilisent d’innombrables certificats auto-signés finissent souvent par avoir une visibilité floue de l’infrastructure de certificats. Malheureusement, si une brèche se produit dans votre réseau organisationnel, vous ne saurez pas si elle est due à un certificat auto-signé compromis et à la clé privée qui lui est associée.

Non-respect des exigences de sécurité

Les certificats numériques émis par des autorités de certification de confiance maintiennent des normes fiables, tandis que les certificats auto-signés sont générés en interne, et ils sont très rarement alignés sur les dernières normes de sécurité en raison d’un manque de connaissances et de l’incapacité à suivre les meilleures pratiques.

Il est essentiel de gérer et de surveiller tous les certificats et clés numériques existant au sein d’un réseau d’entreprise. Tous les certificats, qu’ils soient émis par des CA ou auto-signés, responsables du fonctionnement des sites internes et publics, doivent être sécurisés et protégés et faire l’objet d’une surveillance constante.

Pour les services LAN internes uniquement, vous pouvez utiliser des certificats auto-signés, mais vous devez mettre en place une politique rigoureuse, pour vous assurer que le serveur de CA émettrice est bien protégé des cybercriminels et se trouve dans un endroit qui n’est pas accessible par tous les employés de votre organisation, et que vous disposez d’outils de surveillance et d’une équipe chargée de gérer le parc de certificats.