Pourquoi les certificats racine d'autorité de certification sont-ils tous signés SHA-1 (car SHA-1 est obsolète)?

67

Je comprends que les certificats SSL ne peuvent plus être signés avec SHA-1. Pourtant, tous les certificats racine de l'autorité de certification sont signés SHA-1 (la plupart du temps). Cela signifie-t-il que le même algorithme auquel on ne fait plus confiance pour "you grandma SSL shop" convient parfaitement au certificat le plus sécurisé du monde?

Est-ce que je manque quelque chose? (utilisation de la clé? taille de la clé?)

ssl ssl-certificate certificate-authority

— 131
source

9

Il n'est pas vrai que "tous" les certificats racines de l'autorité de certification sont SHA1.

— Greg Askew

5

Les certificats racine sont comme des hypothèses de départ dans une vision du monde. Il faut de la foi pour leur faire confiance.

— Roy Tinker

@RoyTinker sauf cogito ergo sum (voir le doute radical, et sa réponse: scepticisme cartésien )?

— Nick T

1

Cross-stack: security.stackexchange.com/questions/120301/… et superuser.com/questions/1122069/…

— dave_thompson_085

6

@ NickT: Soyez prudent - Cogito ergo cogito ;-)

— tonysdg Le

106

La signature des certificats de l'autorité de certification racine n'a aucune importance, car il n'est pas nécessaire de les vérifier. Ils sont tous auto-signés.

Si vous faites confiance à un certificat d'autorité de certification racine, il n'est pas nécessaire de vérifier sa signature. Si vous ne lui faites pas confiance, sa signature est sans valeur pour vous.

Edit: il y a quelques commentaires très pertinents ci-dessous. Je ne me sens pas à l'aise de les copier ou de les reformuler et de leur faire crédit à la place de leurs auteurs. Mais je souhaite que les gens ajoutent des explications à cette réponse.

— utilisateur2233709
source

3

La question de savoir pourquoi ils sont signés est posée

— Richard Tingle

42

Parce que le système ne prend pas en charge les certificats non signés.

— Cessez de nuire à Monica

Il me semble que le problème lié à un certificat racine fissurable n’est pas "vous ne savez pas où vous avez obtenu le certificat racine", mais plutôt "vous ne savez pas qui a été en mesure de déchiffrer ce certificat et de l’utiliser. de signer ce qu'ils veulent. " Et il ressort de votre réponse que les deux (cert et cert-signature) sont des préoccupations distinctes et que le cert lui-même est convenablement sécurisé et infranchissable?

— Dewi Morgan

20

J'irais même plus loin que "il n'est pas nécessaire de les vérifier". Le but de la signature dans une chaîne de certificats est qu'une autorité supérieure certifie une autorité inférieure. Pour une autorité de certification racine, il n'y a pas d'autorité supérieure par définition (c'est ce que signifie "racine"), il n'y a donc personne qui pourrait signer le certificat . Comme, comme cela a été mentionné, les certificats doivent être signés, les autorités de certification racines sont signées avec une signature fictive, et le moyen le plus simple de procéder consiste à s'auto-signer. Ainsi, non seulement il n’est pas nécessaire de vérifier, l’ idée même de vérifier la signature d’une autorité de certification racine n’est pas sensuelle.

— Jörg W Mittag Le

13

@DewiMorgan Vous ne pouvez pas "craquer" un certificat racine avec une collision de hachage, car le client fait confiance au certificat lui - même , pas à sa (auto) signature. Vous devez récupérer la clé privée, qui est une attaque contre RSA et non sur l'algorithme de hachage.

— Zwol

46

À la fin de la journée, un certificat racine est auto-signé. Il n'est jamais signé par une autre entité sauf elle-même. Le certificat racine obtient sa confiance par le biais de processus hors bande, par exemple en le soumettant à la liste des éditeurs approuvés du navigateur ou en le faisant accepter par Microsoft pour insertion dans la liste par défaut des éditeurs approuvés Windows.

Ces certificats (et les entreprises qui les ont auto-signés) sont (prétendument, espérons-le) minutieusement contrôlés par d'autres moyens que leur signature.

— Mark Henderson
source

2

Sans parler de la mise à jour d'un certificat racine, il faut repasser par ce processus hors bande.

— Kaithar

4

+1 pour le "prétendument, espérons-le"

— Nathan Osman

6

Le seul cas où cela compte est que si la racine est signée par SHA-1, elle peut être révoquée par SHA-1. C'est-à-dire que quelqu'un qui peut attaquer SHA-1 peut construire une révocation pour la racine. Et je suis absolument sûr que le navigateur ne sait pas comment le conserver, le vandalisme n'a donc rien fait de plus que de supprimer les connexions SSL. Quel paraisseux.

— Joshudson
source

1

C'est une idée intéressante, mais je doute que cela fonctionne de cette façon. Mon hypothèse est que chaque agent aurait son propre comportement, mais je doute que tous les développeurs aient eu l’idée que la liste de révocation serait utilisée pour gérer la révocation des certificats de racine. À tout le moins, si cela fonctionnait dans certains cas, cela serait dû à une abstraction de la révocation de logiciels et non intentionnellement par les développeurs.

— Peter Oehlert

1

Comme une note sur celui - ci, QUELQUES CA ont déjà été mettre à jour leurs certificats racine et intermédiaires à SHA256 de toute façon.

Je sais que l'année dernière, GlobalSign mettait à jour leurs certificats, de même que nos certificats de signature de code. J'ai donc dû ajouter leur nouvelle chaîne à celles-ci également.

Vous pouvez vérifier quels certificats spécifiques ont été mis à jour et lesquels ils ont mis à jour mais ont également laissé un certificat SHA1 hérité pour ici => 1

J'espère que ça t'as aidé.

— B.Kaatz
source

0

Pour une autorité de certification racine, vous vous fiez à la clé publique de l'autorité de certification, regroupée dans le tube cathodique, quelle que soit sa signature automatique.

Décrire l'autorité de certification en utilisant le format de fichier .CRT au lieu d'une clé publique brute .PEM permet de regrouper plus de détails, par exemple le nom de l'autorité de certification, (encore une fois, la signature est sans valeur)

— 131
source

-1

Les navigateurs acceptent les très anciens certificats racine SHA1 épinglés , déjà très fiables, datant pour la plupart de la période 2006 ou antérieure , mais pas de nouveaux certificats. Rappelez-vous quand Firefox et Chrome étaient versionnés en utilisant des chiffres uniques?

Les certificats échouent si l'autorité de certification racine utilise des certificats SHA1 avec le paramètre Non avant défini sur une valeur postérieure à 2014. Les restrictions de date réelles dépendent du navigateur ou de l'application. Le cabforum WebCA l'a clairement montré il y a plusieurs années. Testez vous-même par:

Créez une infrastructure d'autorité de certification racine privée signée avec un SHA1, appelez-la rootSHA1
Demandez à rootSHA1 de créer une autorité de certification "émettrice" ou "intermédiaire" qui émet des certificats avec un certificat lié à la racine. Appelez-le intermédiaireSHA256.
Demandez à l’AC émettrice intermédiaire SH256 de générer un certificat signé avec un hachage sha256 ou supérieur. Appelez-le webServerSHA256.
Installez webServerSHA256 dans le WebServerSHA56.mydomain.com.
Installez les certificats rootSHA1, intermédiaireSHA256 et webServerSHA256 aux emplacements appropriés dans Google Chrome. Installez la racine sur les autorités de certification racines de confiance et les autres avec une chaîne de certificats.
Accédez à la page https://webServerSHA256.mydomain.com/ de Google Chrome et vérifiez qu'il n'y a pas de cadenas vert pour webServerSHA256. Le test échoue.

— rjt
source

C'est tout à fait faux. Les certificats intermédiaires (et EE./leaf) nécessitent SHA2, mais pas les racines. Les chaînes de certificats de Google, par l'intermédiaire de leur autorité de certification privée (Google Internet Authority G3), se rendent à la racine R2 de GlobalSign - SHA1 - et (sans surprise) sont acceptées par Chrome.

— dave_thompson_085

Oui, ces certificats SHA1 épinglés sont acceptés, mais pas les nouveaux certificats racine SHA1, même si vous les ajoutez à votre propre magasin de certificats de racine approuvée. Ajout d'un cas de test à ma réponse.

— rjt