À la suite du bogue Heartbleed, de nombreuses personnes sont confrontées à la perspective décourageante (et coûteuse) de remplacer les certificats SSL sur les systèmes vulnérables. En effet, il est possible que les clés privées des certificats SSL exposés aient été compromises ou non. En fin de compte, comme il n'y a aucun moyen de savoir avec certitude si vos clés privées ont été compromises, beaucoup choisissent de remplacer les certificats SSL du ou des systèmes affectés.
Mais est-il vraiment nécessaire d'utiliser des certificats publics coûteux pour tous vos besoins en matière de certificats SSL ? Dans de nombreux cas, la réponse est certainement oui. Mais ce n'est pas toujours le cas.
Au cours de ma carrière en tant que consultant PKI , j'ai souvent rencontré des certificats SSL publiquement enracinés utilisés dans des endroits où des certificats privés auraient certainement suffi. La décision d'utiliser des certificats publics est prise pour diverses raisons : la perception d'un niveau élevé de fiabilité et d'assurance et l'opportunité commerciale, pour n'en citer que quelques-unes. Les administrateurs décident souvent d'utiliser des certificats publics parce que "c'est comme ça qu'on a toujours fait".
Peut-être que le bug Heartbleed peut être utilisé pour revoir certaines de ces décisions.
À mon avis, la décision d'utiliser un certificat public doit être fondée sur les exigences de l'application SSL ( PKI ). La décision ne doit pas être basée sur le "FUD" - la peur, l'incertitude et le doute - ni sur l'inertie des entreprises, et encore moins sur des idées fausses.
Et je dis "devrait", car j'ai souvent constaté que les exigences de l'application PKI ne sont pas les principaux moteurs de ce processus de décision. Les administrateurs chargés des applications prennent souvent la décision d'utiliser des certificats publiquement enracinés plutôt que des certificats privés en se basant sur la perception (erronée) que les certificats SSL publiquement enracinés sont d'une certaine manière plus dignes de confiance, ou ont d'une certaine manière plus d'assurance que n'importe quel certificat SSL qu'ils pourraient générer de manière privée. Bien que cela puisse être le cas, nous avons tous vu des cas où ce n'était pas le cas.
J'ai participé à de nombreux efforts de conception de PKI privés qui ont abouti à des ICP d'entreprise capables de fournir des niveaux d'assurance exceptionnellement élevés, dont les certificats sont entièrement documentés par leur CP/CPS et validés par des auditeurs externes. Inversement, nous avons tous lu récemment dans la presse les lacunes de certaines ICP très publiques en matière de confiance.
Comme vous pouvez le constater, il est tout à fait plausible que le site PKI existant d'un administrateur puisse fournir une assurance plus que suffisante pour les besoins de ses certificats SSL , souvent à un coût nettement inférieur. Sur quoi un administrateur chargé de renouveler son certificat SSL doit-il donc fonder sa décision "public/privé" ? La réponse se résume souvent à la "confiance" dans le certificat, et non à l'"assurance". En d'autres termes, qui devra faire confiance à votre certificat ? Et d'où cette confiance devra-t-elle être établie ?
En tant que propriétaire d'une application, vous devez savoir qui doit faire confiance à votre certificat SSL . En d'autres termes, qui utilisera les certificats ? Les téléphones portables ? Les ordinateurs portables de l'entreprise ? Les fournisseurs ? Le public ?
Si la réponse à la question de confiance est une liste d'entités sur lesquelles on n'a absolument aucun contrôle informatique, on ne peut pas supposer que le certificat de l'autorité de certification racine privée bénéficiera d'une quelconque confiance. Cela nécessitera presque certainement que votre nouveau certificat SSL soit ancré publiquement.
Mais si la réponse à cette question de confiance est une liste d'entités sur lesquelles vous avez un contrôle informatique complet, comme les ordinateurs portables, les serveurs et les utilisateurs de l'entreprise, il est fort probable que ces entités fassent déjà confiance, ou puissent faire confiance à votre racine privée. Cela signifie que vous avez de fortes chances d'utiliser un certificat SSL à racine privée.
Alors que nous sommes tous confrontés aux retombées du bug Heartbleed, il convient d'envisager une nouvelle approche, éventuellement plus raffinée, pour remplacer les certificats concernés. Vous pouvez peut-être utiliser vos propres certificats SSL .
