Certificat autosigné
En cryptographie et en sécurité informatique, un certificat autosigné (en anglais, self-signed certificate) est un certificat de clé publique qu'un utilisateur émet en son propre nom, par opposition à un certificat émis par une autorité de certification. Un tel certificat est facile à produire et ne coûte rien. Cependant, il ne fournit aucune valeur de confiance.
Par exemple, si le propriétaire d'un site Web utilise un certificat autosigné pour fournir des services HTTPS, les personnes qui visitent ce site ne peuvent pas être certaines d'être connectées à la destination prévue. Un tiers malveillant pourrait rediriger la connexion en utilisant un autre certificat autosigné portant le même nom de titulaire. La connexion est chiffrée, mais ne mène pas à la destination prévue. En comparaison, un certificat signé par une autorité de certification empêche cette attaque, car le navigateur Web de l'utilisateur valide le certificat auprès de l'autorité de certification émettrice. Le certificat de l'attaquant échoue à cette validation.
Les certificats autosignés ont néanmoins leurs propres utilisations limitées. Ils ont une valeur de confiance totale lorsque l'émetteur et l'utilisateur unique sont la même entité. Par exemple, le système de chiffrement de fichiers de Microsoft Windows (Encrypting File System) émet un certificat autosigné au nom de l'utilisateur qui chiffre et l'utilise pour déchiffrer les données de manière transparente à la volée. Un autre exemple est le certificat racine, qui est une forme de certificat autosigné.
Avantages
modifierLes certificats autosignés peuvent être créés gratuitement à l'aide d'une grande variété d'outils, notamment OpenSSL, Java's keytool, Adobe Reader, wolfSSL et Keychain (en) d'Apple. Ils sont faciles à personnaliser ; par exemple, ils peuvent avoir une taille de clé plus longue ou contenir des métadonnées supplémentaires. Leur utilisation n'implique pas les problèmes de confiance envers des tiers qui peuvent signer des certificats de façon incorrecte. Les transactions par certificats autosignés présentent généralement une surface d'attaque bien plus réduite, car elles éliminent à la fois la validation complexe de la chaîne de certificats[1] et les contrôles de révocation de l'autorité de certification telles que les listes de révocation de certificats et les protocoles de vérification de certificat en ligne (en anglais, Online Certificate Status Protocol ou OCSP).
Questions de confiance
modifierDans une infrastructure à clés publiques basée sur une autorité de certification, les parties engagées dans une communication sécurisée doivent faire confiance à une autorité de certification, c'est-à-dire placer les certificats de l'autorité de certification dans une liste blanche de certificats de confiance. Les développeurs de navigateurs Web peuvent utiliser les procédures spécifiées par le CA/Browser Forum (en) pour inscrire sur une liste blanche des autorités de certification publiques et bien connues. Les groupes individuels et les entreprises peuvent inscrire sur une liste blanche des certificats d'autorité de certification privés supplémentaires. Les problèmes de confiance d'une entité acceptant un nouveau certificat autosigné sont similaires à ceux d'une entité faisant confiance à l'ajout d'un nouveau certificat d'autorité de certification. Les parties d'une infrastructure à clés publiques autosignée doivent établir la confiance entre elles (en utilisant des procédures extérieures à l'infrastructure à clés publiques) et confirmer le transfert exact des clés publiques, par exemple en comparant le hachage cryptographique du certificat hors bande.
Il existe de nombreuses différences subtiles entre les certificats signés par une autorité de certification et les certificats autosignés, notamment en ce qui concerne la confiance que l'on peut accorder aux affirmations de sécurité du certificat. Certaines autorités de certification peuvent vérifier l'identité de la personne à laquelle elles délivrent un certificat ; par exemple, l'armée américaine délivre ses Common Access Cards (en) en personne, avec plusieurs autres formes d'identification. L'autorité de certification peut attester de telles valeurs d'identité en les incluant dans le certificat signé. L'entité qui valide le certificat peut faire confiance aux informations contenues dans ce certificat, dans la même mesure qu'elle fait confiance à l'autorité de certification qui l'a signé (et, par voie de conséquence, aux procédures de sécurité utilisées par l'autorité de certification pour vérifier les informations attestées).
En revanche, avec un certificat autosigné, la confiance dans les valeurs du certificat est plus compliquée, car l'entité possède la clé de signature et peut toujours générer un nouveau certificat avec des valeurs différentes. Par exemple, les dates de validité d'un certificat autosigné peuvent ne pas être fiables, parce que l'entité peut toujours créer et signer un nouveau certificat contenant une plage de dates valides.
Les valeurs d'un certificat autosigné ne sont fiables que si elles ont été vérifiées hors bande lors de l'acceptation du certificat et s'il existe une méthode permettant de vérifier que le certificat autosigné n'a pas été modifié après sa validation. Par exemple, la procédure de confiance d'un certificat autosigné comprend une vérification manuelle des dates de validité, et un hachage du certificat est incorporé dans la liste blanche[2]. Lorsqu'une entité présente le certificat pour le valider, elle vérifie d'abord que le hachage du certificat correspond au hachage de référence dans la liste blanche, et s'il correspond (indiquant que le certificat autosigné est le même que celui qui a été officiellement reconnu), alors les dates de validité du certificat peuvent être reconnues. Un traitement spécial des champs de certificat X.509 pour les certificats autosignés peut être trouvé dans la RFC 3280[1].
La révocation des certificats autosignés diffère de celle des certificats signés par une autorité de certification. Par nature, aucune entité (autorité de certification ou autres) ne peut révoquer un certificat autosigné. Mais on peut invalider un certificat autosigné en le retirant de la liste blanche de confiance[3].
Références
modifier- (en) Russ Housley, Tim Polk, Warwick S. Ford, David Solo, « Certificate and CRL Profile », Request for comments no 3280,
- (en) « How to bypass SSLHandshakeException » [archive du ] (consulté le )
- (en) « Internet X.509 Public Key Infrastructure Certificate and CRL Profile », Request for comments no 2459,