Je pense qu’au moins une partie du problème pourrait être lié à ce qui est apparemment un bug connu de Chrome (section "Issue 2: Out-of-date NSS and cross-signed roots") :
A bug in NSS caused Chrome on Linux to use cached cross-signed roots even when a shorter and newer chain existed.
Je pense que c’est ce qui explique la chaîne à six niveaux observé avec Chrome.
Le dernier certificat intermédiaire envoyé par LinuxFR.org (CN=USERTrust RSA Certification Authority, serial 13:EA:28:70:5B:F4:EC:ED:0C:36:63:09:80:61:43:36) est signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A.
Il existe (au moins) deux certificats utilisant cette clef :
CN=AddTrust External CA Root, serial 0x1, auto-signé;
CN=AddTrust External CA Root, serial 51:26:0A:93:1C:E2:7F:9C:C3:A5:5F:79:E0:72:AE:82, signé par la clef 53:32:D1:B3:CF:7F:FA:E0:F1:A0:5D:85:4E:92:D2:9E:45:1D:B4:4F.
Cette clef 53:32:D1.etc. est utilisée par (au moins) trois certificats :
CN=UTN - DATACorp SGC, serial 44:BE:0C:8B:50:00:21:B4:11:D3:2A:68:06:A9:AD:69, auto-signé
CN=UTN - DATACorp SGC, serial 46:EA:F0:96:05:4C:C5:E3:FA:65:EA:6E:9F:42:C6:64, signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A (celle des certificats AddTrust External CA Root ci-dessus, vous suivez ?), révoqué le 14 décembre
CN=UTN - DATACorp SGC, serial 53:7B:76:56:4F:29:7F:14:DC:69:43:E9:22:AD:2C:79, lui aussi signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A et lui aussi révoqué le 14 décembre.
On est donc bien dans le cas « racines cross-signées » entre AddTrust External CA Root et UTN - DATACorp SGC.
Dans les versions récentes de NSS, seul le certificat AddTrust External CA Root auto-signé est présent dans le magasin des Builtin Object Tokens (les certificats codés « en dur » dans le navigateur). Cela ne laisse donc qu’une racine possible pour rattacher le dernier certificat intermédiaire envoyé par LinuxFR.org, et il n’y a pas de problème.
Mais si le magasin des certificats cachés (les certificats que le navigateur accumule au gré de la navigation) vient à contenir à la fois la version cross-signée du certificat AddTrust External CA Rootet l’une des deux versions cross-signées du certificat UTN - DATACorp SGC, le navigateur peut construire la chaîne de certification suivante :
USERTrust RSA Certification Authority → AddTrust External CA Root (version cross-signée, en cache) → UTN - DATACorp SGC (version cross-signée, en cache) → AddTrust External CA Root (version auto-signée, dans le magasin en dur)
On est donc bien, me semble-t-il, dans le cas du bug évoqué plus haut (ou un bug similaire), où le navigateur construit une chaine de certification à rallonge en utilisant des certificats cachés alors qu’une chaîne plus courte est possible.
Il reste que je ne comprends toujours pas comment/pourquoi la construction de la chaine de certification varierait en fonction du FAI utilisé pour se connecter...
[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 10.
Je pense qu’au moins une partie du problème pourrait être lié à ce qui est apparemment un bug connu de Chrome (section "Issue 2: Out-of-date NSS and cross-signed roots") :
Je pense que c’est ce qui explique la chaîne à six niveaux observé avec Chrome.
Le dernier certificat intermédiaire envoyé par LinuxFR.org (
CN=USERTrust RSA Certification Authority, serial13:EA:28:70:5B:F4:EC:ED:0C:36:63:09:80:61:43:36) est signé par la clefAD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A.Il existe (au moins) deux certificats utilisant cette clef :
CN=AddTrust External CA Root, serial0x1, auto-signé;CN=AddTrust External CA Root, serial51:26:0A:93:1C:E2:7F:9C:C3:A5:5F:79:E0:72:AE:82, signé par la clef53:32:D1:B3:CF:7F:FA:E0:F1:A0:5D:85:4E:92:D2:9E:45:1D:B4:4F.Cette clef
53:32:D1.etc.est utilisée par (au moins) trois certificats :CN=UTN - DATACorp SGC, serial44:BE:0C:8B:50:00:21:B4:11:D3:2A:68:06:A9:AD:69, auto-signéCN=UTN - DATACorp SGC, serial46:EA:F0:96:05:4C:C5:E3:FA:65:EA:6E:9F:42:C6:64, signé par la clefAD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A(celle des certificatsAddTrust External CA Rootci-dessus, vous suivez ?), révoqué le 14 décembreCN=UTN - DATACorp SGC, serial53:7B:76:56:4F:29:7F:14:DC:69:43:E9:22:AD:2C:79, lui aussi signé par la clefAD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1Aet lui aussi révoqué le 14 décembre.On est donc bien dans le cas « racines cross-signées » entre
AddTrust External CA RootetUTN - DATACorp SGC.Dans les versions récentes de NSS, seul le certificat
AddTrust External CA Rootauto-signé est présent dans le magasin des Builtin Object Tokens (les certificats codés « en dur » dans le navigateur). Cela ne laisse donc qu’une racine possible pour rattacher le dernier certificat intermédiaire envoyé par LinuxFR.org, et il n’y a pas de problème.Mais si le magasin des certificats cachés (les certificats que le navigateur accumule au gré de la navigation) vient à contenir à la fois la version cross-signée du certificat
AddTrust External CA Rootet l’une des deux versions cross-signées du certificatUTN - DATACorp SGC, le navigateur peut construire la chaîne de certification suivante :USERTrust RSA Certification Authority→AddTrust External CA Root(version cross-signée, en cache) →UTN - DATACorp SGC(version cross-signée, en cache) →AddTrust External CA Root(version auto-signée, dans le magasin en dur)On est donc bien, me semble-t-il, dans le cas du bug évoqué plus haut (ou un bug similaire), où le navigateur construit une chaine de certification à rallonge en utilisant des certificats cachés alors qu’une chaîne plus courte est possible.
Il reste que je ne comprends toujours pas comment/pourquoi la construction de la chaine de certification varierait en fonction du FAI utilisé pour se connecter...