Auteur Sujet: 1er octobre 2021: nombreux changements pour Let's Encrypt  (Lu 12037 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #72 le: 11 janvier 2021 à 15:50:44 »
Cela pourrait bientôt changer... Il y a eu une annonce officielle récemment du Chrome Root Program : https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ. On trouve aussi depuis quelques semaines la liste de pré-requis pour les autorités de certification (https://www.chromium.org/Home/chromium-security/root-ca-policy)
A voir, mais si Google est toujours en mesure de pousser des mises à jour de Chrome à ces appareils via le Play Store, cela pourrait changer en partie la donne.

J'ai profité d'un webinar Google France sur Chrome organisé aujourd'hui pour poser la question dans quand arriverait Chrome avec sa propre liste de certificats racine de confiance.

Je n'ai pas eu de date, mais un chantier important et pas que pour la problématique Let's Encrypt, également pour des systèmes d'exploitation qui ont des certificats pour intercepter le trafic https. Une liste de certificats racine de haute qualité sont aujourd'hui nécessaire.

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #73 le: 24 septembre 2021 à 13:54:26 »
Le certificat racine de Let's Encrypt expire !

Le 30 septembre 2021, le certificat racine que Let's Encrypt utilise actuellement, le certificat IdentTrust DST Root CA X3, expirera. Je parie que certaines choses vont probablement casser ce jour-là, alors voici ce que vous devez savoir !

C'est une longue histoire

Tous les certificats qui alimentent HTTPS sur le Web sont émis par une autorité de certification, une organisation de confiance reconnue par votre appareil/OS. Ces certificats sont intégrés à votre système d'exploitation et sont généralement mis à jour dans le cadre du processus normal de mise à jour de votre système d'exploitation. Le certificat ici qui va poser problème est celui-ci, IdenTrust DST Root CA X3.



Comme vous pouvez le voir, le temps presse et nous nous rapprochons de la date d'expiration du 30 septembre 2021 mais ce n'est pas seulement une date d'expiration, c'est un horodatage d'expiration : Not After : Sep 30 14:01:15 2021 GMT

Une fois cette autorité de certification racine expirée, les clients, comme les navigateurs Web, ne feront plus confiance aux certificats émis par cette autorité de certification.

La fin est proche!

Ce ne sera pas la première fois qu'un certificat CA racine expirera et j'imagine qu'il suivra la même tendance que les expirations précédentes où les choses se cassent. Si le certificat racine sur lequel votre chaîne de certificats est ancrée a expiré, il y a de fortes chances que cela entraîne un échec. Cela s'est produit l'année dernière, le 30 mai à 10:48:38 GMT 2020 pour être exact, lorsque la racine CA externe AddTrust a expiré et a emporté un tas de choses avec elle. Des organisations comme Roku, Stripe, Spreedly et bien d'autres ont eu des problèmes et elles n'étaient pas les seules, même RedHat avait quelque chose à dire sur l'événement.

Dans des circonstances normales, cet événement, l'expiration d'une autorité de certification racine, ne vaudrait même pas la peine d'être évoqué car la transition d'un ancien certificat racine vers un nouveau certificat racine est totalement transparente. La raison pour laquelle nous avons un problème est que les clients ne sont pas mis à jour régulièrement et si le client n'est pas mis à jour, la nouvelle autorité de certification racine qui remplace l'ancienne autorité de certification racine expirée n'est pas téléchargée sur l'appareil.

Let's Encrypt a grandi

Au cours de la dernière année seulement, Let's Encrypt a considérablement augmenté sa part de marché et à mesure qu'une autorité de certification devient plus grande, ses certificats permettent à une plus grande partie du Web de fonctionner et, par conséquent, lorsque quelque chose comme cela se produit, ils ont le potentiel de causer plus de problèmes. Cela n'a rien à voir avec ce que Let's Encrypt a fait ou n'a pas fait, cela revient toujours au même problème sous-jacent que les appareils de l'écosystème ne sont pas mis à jour comme ils devraient l'être.

Compte tenu de la différence de taille relative entre Let's Encrypt et AddTrust, j'ai le sentiment que l'expiration de la racine IdenTrust peut potentiellement causer plus de problèmes. Personne ne sait vraiment à quel point cela pourrait être un problème, cela pourrait avoir des conséquences similaires à l'expiration d'AddTrust, ou il pourrait y avoir des circonstances imprévues et cela pourrait être bien pire, votre supposition est aussi bonne que la mienne.

Que fait Let's Encrypt à ce sujet ?

Comme je l'ai dit ci-dessus, ce problème ne se produit pas à cause de tout ce que Let's Encrypt a fait ou n'a pas fait, cela se produit parce que tous les certificats finissent par expirer et si les appareils ne sont pas mis à jour, ils ne recevront pas les nouveaux certificats de remplacement. Cela dit, Let's Encrypt ne s'est pas assis et s'est tourné les pouces à l'approche de la date d'expiration, ils ont travaillé dur pour essayer de trouver une solution.

En avril 2019, j'ai écrit Let's Encrypt prévoit de passer à la racine ISRG, où Let's Encrypt avait prévu de passer de la racine IdenTrust à sa propre racine, ISRG Root X1, qui expire le 4 juin 2035, ce qui nous donne un certain nombre d'années. Le problème était que peu d'appareils avaient reçu les mises à jour nécessaires qui incluent ce nouveau ISRG Root X1, publié 4 ans auparavant en 2015 ! Si un grand nombre d'appareils n'ont pas reçu de mise à jour pour inclure ce nouveau certificat racine, ils ne lui feront tout simplement pas confiance. Il s'agit essentiellement du même problème que nous rencontrons actuellement avec l'expiration de la racine IdenTrust, car les périphériques clients n'ont pas été mis à jour, ils n'ont pas non plus reçu la nouvelle racine ISRG X1. La transition a été reportée.

En septembre 2020 je devais écrire un autre article, Let's Encrypt reporte la transition ISRG Root, pour expliquer, pour la troisième fois, que Let's Encrypt avait à nouveau reporté la transition. Ils ont cité les préoccupations suivantes : "En raison de préoccupations concernant la propagation insuffisante de la racine ISRG sur les appareils Android, nous avons décidé de déplacer la date à laquelle nous commencerons à servir une chaîne à notre propre racine au 11 janvier 2021."

Cela se traduit vaguement par le fait que les appareils Android n'ont pas reçu de mise à jour depuis plus de 4 ans, ce qui signifie que ces appareils n'avaient toujours pas reçu l'ISRG Root X1, ce qui signifie qu'ils ne lui feraient pas confiance. Let's Encrypt ne peut pas passer à l'émission à partir de la nouvelle racine, mais la racine IdenTrust a encore 1 an de vie et le temps presse maintenant.

En fin de compte, quelque chose d'un peu inattendu s'est produit qui pourrait simplement réduire l'impact grave de cet événement et le rendre un peu plus acceptable. Étant donné que les anciens appareils Android ne vérifient pas la date d'expiration d'un certificat racine lorsqu'ils l'utilisent, Let's Encrypt peut continuer à se connecter au certificat racine expiré sans aucun problème sur ces appareils plus anciens. Cela introduit une certaine complexité à l'avenir, mais en fin de compte, l'objectif est d'étendre la compatibilité des appareils Android pour les certificats Let's Encrypt.

Pour que cela fonctionne, Let's Encrypt a dû obtenir une signature croisée pour son propre certificat racine ISRG X1 de la racine CA X3 IdenTrust DST expirée, mais cela n'aiderait pas du tout à moins que la racine à signature croisée ne soit valide plus longtemps que le racine de signature, ce qui est le cas. Le nouveau certificat ISRG Root X1 est valide plus longtemps que l'IdenTrust DST Root CA X3 qui l'a signé !

Comme nous le savons maintenant, le IdenTrust DST Root CA X3 expire le 30 septembre 2021, mais le nouveau ISRG Root X1 avec signature croisée n'expire que le 30 septembre 2024 !

En étendant la validité de la nouvelle racine à signature croisée au-delà de celle de la racine de signature, Let's Encrypt a trouvé un moyen de contourner les règles et de nous acheter 3 ans supplémentaires jusqu'à ce que ce problème se reproduise. Certaines personnes ne sont pas satisfaites du jeu sournois, mais il semble que cela respecte les règles, même si ce n'est peut-être pas ce que tout le monde aurait attendu ou préféré. Cette nouvelle racine ISRG X1 à signature croisée ne doit pas non plus être confondue avec la racine ISRG X1 existante qui n'a pas changé et plus de détails peuvent être trouvés ici.

Espérons que cela aidera à atténuer de nombreux problèmes en attente, mais ce n'est pas une solution à tous les problèmes, car tout client qui applique la date d'expiration du certificat racine sur lequel il s'ancre échouera toujours.

Les clients affectés

L'un des clients notables qui sera toujours affecté par cette expiration dépend de la bibliothèque OpenSSL 1.0.2 ou antérieure, version 22 janvier 2015 et dernière mise à jour en tant qu'OpenSSL 1.0.2u le 20 décembre 2019. OpenSSL a publié un article de blog détaillant quelles mesures les personnes concernées peuvent prendre, mais elles nécessitent toutes une intervention manuelle pour éviter le blocage, tous les détails sont ici.

Le bref aperçu des options est :
1 Supprimez le certificat racine IdenTrust DST Root CA X3 et installez manuellement le certificat racine ISRG Root X1 (pas celui à signature croisée).
2 Si vous utilisez des commandes OpenSSL comme verifyou s_clientvous pouvez ajouter le --trusted_firstdrapeau si possible.
3 Demandez au serveur de servir une chaîne de certificats alternative qui va directement à la racine ISRG X1 (pas celle à signature croisée), mais cela cassera les appareils Android mentionnés ci-dessus.

Cette page de documentation de Let's Encrypt contient une liste de clients qui font uniquement confiance au certificat IdenTrust DST Root CA X3 et ensuite se trouve la liste des plates-formes qui font confiance à ISRG Root X1. J'ai mélangé ces deux listes pour produire la liste suivante de clients qui seront incompatibles Let's Encrypt après l'expiration de IdenTrust DST Root CA X3.

Clients qui seront incompatibles Let's Encrypt à partir du 1er octobre 2021 :
- OpenSSL <= 1.0.2
- Windows < XP SP3
- macOS < 10.12.1
- iOS < 10 (l'iPhone 5 est le modèle le plus bas pouvant accéder à iOS 10)
- Android < 7.1.1 (mais >= 2.3.6 fonctionnera si le signe croisé ISRG Root X1 est servi)
- Mozilla Firefox < 50
- Ubuntu < 16.04
- Debian < 8
- Java 8 < 8u141
- Java 7 < 7u151
- NSS < 3,26
- Amazon FireOS (navigateur Silk)

Les plates-formes dont je ne suis toujours pas sûr et qui auront besoin d'une enquête plus approfondie pour voir si elles échoueront après l'expiration de IdenTrust DST Root CA X3 sont :
- Cyanogène > v10
- Jolla Sailfish OS > v1.1.2.16
- Kindle > v3.4.1
- Blackberry >= 10.3.3
- Console de jeu PS4 avec firmware >= 5.00
- IIS

La réponse à la question « que se passera-t-il lorsque la racine IdenTrust expire ? » dépend de l'étendue des types de clients énumérés ci-dessus. Je ne sais pas ce qui circule sur le Web, et je ne sais pas non plus ce qui dépend de ces choses. Une chose que je sais, cependant, c'est qu'au moins quelque chose, quelque part va se briser.

Mise à jour du 21 septembre 2021

J'ai ajouté IIS à la liste « incertain », car certains rapports [ 1 ][ 2 ] suggèrent qu'une intervention manuelle est nécessaire pour une transition en douceur.


Source : Scott Helme, chercheur en sécurité, entrepreneur et conférencier international, le 20 septembre 2021

Traduit et légérement raccourci par Vivien

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 636
  • Chambly (60)
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #74 le: 24 septembre 2021 à 21:08:44 »
Ce qui est gênant, c'est l'opposition entre les vieilles versions d'Android et OpenSSL 1.0.2.

Si le serveur envoie le ISRG Root X1 signé par DST Root CA X3 :
 - Les vielles versions d'Android contiennent la racine DST Root CA X3, et ne vérifient pas son expiration, donc ça passe.
 - Si la racine DST Root CA X3 est embarquée, OpenSSL 1.0.2 voit la chaîne avec une racine expirée et refuse, même si la racine ISRG Root X1 est présente.

Si le serveur envoie le ISRG Root X1 racine (ou juste le reste de la chaîne) :
 - Les vielles versions d'Android n'embarquent pas la racine ISRG Root X1, donc la chaîne est invalide.
 - OpenSSL 1.0.2 fonctionne si la racine ISRG Root X1 est embarquée.

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #75 le: 26 septembre 2021 à 22:00:06 »
On a toujours deux chaînes de certification, pour permettre la compatibilité :



Jusqu'au 3 mai 2021 :

Chaîne par défaut : End-entity certificate ← R3 ← DST Root CA X3

Chaîne alternative : End-entity certificate ← R3 ← ISRG Root X1

À partir du 4 mai 2021 :

Chaîne par défaut : End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3
Cette chaîne restera compatible avec de nombreux appareils Android, grâce a la signature croisée étendue expirée.

Chaîne alternative : End-entity certificate ← R3 ← ISRG Root X1
Il s'agit d'une chaîne plus courte, accessible aux personnes via l'API qui n'ont pas besoin de la compatibilité Android de la chaîne plus longue. Vous pouvez choisir cette chaîne avec de nombreux clients ACME, veuillez consulter la documentation du client ACME que vous avez choisi pour plus d'informations.


Après le 29 septembre 2021

Notre chaîne par défaut et notre chaîne alternative ne changeront pas, mais DST Root CA X3 expirera. Les appareils Android depuis la version 2.3.6 continueront de fonctionner. Les appareils non Android qui ne reçoivent pas de mises à jour du système afficheront des erreurs de certificat. Sur certaines plates-formes, l'utilisation de Firefox sera une solution de contournement, car Firefox obtient des mises à jour même sur de nombreux systèmes d'exploitation obsolètes.

Nous publierons périodiquement de nouveaux intermédiaires pour remplacer E1, E2, R3 et R4. Ces intermédiaires seront signés par ISRG Root X1 ou ISRG Root X2, selon leur type de clé.

Septembre 2024

Notre signature croisée étendue DST Root CA X3 expirera. Les appareils Android antérieurs à 7.1.1 afficheront des erreurs de certificat.


Source: community.letsencrypt.org : Modifications de la chaîne de production, le 29 avril 2021

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #76 le: 26 septembre 2021 à 22:15:31 »
Pour mieux comprendre la chaîne End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3, utilisée uniquement par Android < 7.1.1 :

Extension de la compatibilité des appareils Android pour les certificats Let's Encrypt

Nous sommes heureux d'annoncer que nous avons développé un moyen pour les anciens appareils Android de conserver leur capacité à visiter les sites qui utilisent les certificats Let's Encrypt après l'expiration de nos intermédiaires à signature croisée. Nous ne prévoyons plus de changements en janvier qui pourraient causer des problèmes de compatibilité pour les abonnés Let's Encrypt.

Un thème récurrent dans nos articles sur notre prochain changement de chaîne a été notre préoccupation concernant les effets sur les utilisateurs de systèmes d'exploitation Android antérieurs à 7.1.1, dont les appareils ne font pas confiance à notre racine ISRG X1. Grâce à la réflexion innovante de notre communauté et de nos merveilleux partenaires d'IdenTrust, nous disposons désormais d'une solution qui nous permet de maintenir une large compatibilité. Un élément essentiel à notre mission en tant qu'organisation à but non lucratif est d'aider à créer un Web plus sûr et plus respectueux de la vie privée pour le plus grand nombre de personnes possible. Ce travail nous rapproche de cet objectif.

IdenTrust a accepté de délivrer un signe croisé de 3 ans pour notre ISRG Root X1 à partir de leur DST Root CA X3. Le nouveau signe croisé sera quelque peu nouveau car il s'étend au-delà de l'expiration de DST Root CA X3. Cette solution fonctionne car Android n'applique intentionnellement pas les dates d'expiration des certificats utilisés comme ancres de confiance. L'ISRG et IdenTrust ont contacté nos auditeurs et nos programmes racine pour examiner ce plan et s'assurer qu'il n'y avait aucun problème de conformité.

En tant que tel, nous serons en mesure de fournir aux abonnés une chaîne contenant à la fois ISRG Root X1 et DST Root CA X3, garantissant un service ininterrompu à tous les utilisateurs et évitant les ruptures potentielles qui nous inquiétaient.

Nous n'effectuerons pas notre changement de chaîne précédemment planifié le 11 janvier 2021. Au lieu de cela, nous passerons pour fournir cette nouvelle chaîne par défaut fin janvier ou début février. La transition ne devrait avoir aucun impact sur les abonnés de Let's Encrypt, tout comme notre passage à notre intermédiaire R3 plus tôt ce mois-ci.



Quelques détails techniques supplémentaires suivent.

Je suis un développeur client ACME, que dois-je faire ? Si votre client a géré la transition X3 vers R3 en douceur, vous ne devriez pas avoir besoin d'agir. Assurez-vous que votre client utilise correctement le certificat intermédiaire fourni par l'API ACME à la fin de l'émission et ne récupère pas les intermédiaires par d'autres moyens (par exemple, les coder en dur, réutiliser ce qui est déjà sur le disque ou récupérer des URL AIA).

Je suis abonné à Let's Encrypt, que dois-je faire ? Dans la grande majorité des cas, rien. Si vous souhaitez vérifier, assurez-vous que votre client ACME est à jour.

J'utilise un ancien appareil Android, que dois-je faire ? Rien! Nous essayons de nous assurer que ce changement est complètement invisible pour les utilisateurs finaux.

Qu'est-ce qui change exactement ? Aujourd'hui, lorsqu'un abonné récupère son certificat depuis notre API, nous fournissons la chaîne suivante par défaut : Subscriber Certificate < – R3 < – DST Root CA X3 Après ce changement, nous fournirons à la place cette chaîne par défaut : Subscriber Certificate < – R3 < – ISRG Root X1 < – DST Root CA X3 Cela signifie que la chaîne par défaut que nous fournissons aux abonnés sera plus grande qu'auparavant, car elle contient deux intermédiaires au lieu d'un seul. Cela rendra les poignées de main TLS plus grandes et légèrement moins efficaces, mais le compromis en vaut la peine pour la compatibilité supplémentaire.

Mais DST Root CA X3 n'expire-t-il pas ? Le certificat auto-signé qui représente la paire de clés DST Root CA X3 expire. Mais les magasins racine du navigateur et du système d'exploitation ne contiennent pas de certificats en soi, ils contiennent des « ancres de confiance », et les normes de vérification des certificats permettent aux implémentations de choisir d'utiliser ou non des champs sur les ancres de confiance. Android a volontairement choisi de ne pas utiliser le champ notAfter des ancres de confiance. Tout comme notre ISRG Root X1 n'a pas été ajouté aux anciens magasins de confiance Android, DST Root CA X3 n'a pas été supprimé. Ainsi, il peut émettre un signe croisé dont la validité s'étend au-delà de l'expiration de son propre certificat auto-signé sans aucun problème.

Que se passe-t-il lorsque le nouveau signe croisé expire ? Ce nouveau signe croisé expirera au début de 2024. Avant cela, peut-être dès juin 2021, nous apporterons un changement similaire à ce que nous avions l'intention de faire en janvier. Lorsque nous apporterons cette modification, les abonnés auront la possibilité de continuer à utiliser DST Root CA X3 en configurant leur client ACME pour le demander spécifiquement. Si vous êtes un abonné Let's Encrypt qui travaille déjà à atténuer le changement de chaîne (par exemple en configurant des chaînes alternatives ou en encourageant vos utilisateurs sur d'anciens appareils Android à installer Firefox), continuez ce travail afin d'être bien positionné à l'avenir.

Et la chaîne alternative ? Aujourd'hui, certains clients ACME peuvent demander à la place une chaîne alternative, si leur utilisateur l'a configurée. Nous offrons actuellement la possibilité d'obtenir la chaîne : Certificat d'abonné < – R3 < – ISRG Racine X1 Nous continuerons à offrir cette même chaîne comme alternative. Cependant, notez que la plupart des clients ACME n'ont pas encore la possibilité de sélectionner cette chaîne alternative (par exemple, Certbot sélectionne les chaînes en cherchant si elles contiennent un nom d'émetteur donné, mais cette chaîne ne contient aucun nom d'émetteur que le la chaîne de compatibilité élevée ci-dessus ne le fait pas). Nous travaillerons avec les développeurs de clients ACME pour créer des mécanismes de sélection de chaîne plus flexibles à l'avenir.

Qu'est-ce que cela a à voir avec la future chaîne ECDSA ? Ce changement n'est pas lié à notre émission à venir de l'intermédiaire ISRG Root X2 et E1 basé sur l'ECDSA. Nous sommes impatients de les utiliser pour fournir des certificats et des chaînes plus petits et plus efficaces, mais cette offre future n'est pas liée à ce changement.


Source : Let's Encrypt le 21 décembre 2020 par Josh Aas et Aaron Gable

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #77 le: 26 septembre 2021 à 22:33:36 »
Au final les vieux Android ne seront pas coupés de Let's Encrypt avec l'exploitation de cette faille de sécurité qui consiste à ne pas vérifier qu'un certificat racine est expiré.

Il y aura par contre de la casse le 30 septembre.

Voici la liste des systèmes qui seront difficilement utilisables sur Internet :
- Windows XP SP1 et SP2 (le SP3 est ok)
- macOS 10.10.x, 10.11.x et 10.12.0
- iOS 8 et iOS 9
- Ubuntu 14.04 LTS
- Debian 7

Firefox utilisant ses propres certificat, la solution est d’utiliser Firefox pour aller sur Internet, enfin Firefox 50 ou plus récent car Mozilla Firefox 49 et plus ancien sera cassé quel que soit le système d'exploitation.

La dernière version de Firefox pour Windows XP est Firefox 52 ESR, donc cela sera ok.
Pour Windows 2000, c'est Firefox 12, donc cela ne fonctionnera plus sans rajouter à la main le certificat (c'est également une solution pour les PC)

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 636
  • Chambly (60)
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #78 le: 26 septembre 2021 à 23:06:13 »
Il y a aussi le cas d'OpenSSL 1.0.2, qui est gêné par la racine expirée de la chaîne par défaut.
Il faudra enlever le certificat expiré DST Root CA X3, pour que la racine ISRG Root X1 embarquée soit utilisée (cad que la chaîne alternative soit créée en local quand le serveur envoie la chaîne par défaut).

Donc sur un Ubuntu 16.04, ou un 18.04 non mis à jour (ou pour des applications ayant été compilées avec la version d'origine d'OpenSSL), il y aura des problèmes.
Il y aura probablement pas mal de Linux embarqués avec le même problème, car la mise à jour OpenSSL 1.0.x vers 1.1 n'est pas immédiate (il faut tout recompiler, et modifier certaines sources).

xp25

  • Client RED by SFR fibre FttH
  • *
  • Messages: 3 295
  • ↓ 1Gbps | ↑ 500Mbps
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #79 le: 27 septembre 2021 à 00:32:16 »
Est-ce qu'il y a un risque pour les vieilles Freebox (V5HD/Crystal) et certaines vieilles STB style Amino 110 ?

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #80 le: 27 septembre 2021 à 07:31:11 »
OpenSSL en tant que client uniquement, non ?

OpenSSL est massivement utilisé, mais en tant que serveur, non ?

L'article du blog OPenSSL :

OpenSSL 1.0.2 et la la racine expirée de Let's Encrypt

La chaîne de certificats actuellement recommandée telle qu'elle est présentée aux clients Let's Encrypt ACME lorsque de nouveaux certificats sont émis contient un certificat intermédiaire (ISRG Root X1) qui est signé par un ancien certificat DST Root CA X3 qui expire le 2021-09-30. Dans certains cas, la version OpenSSL 1.0.2 considérera les certificats émis par Let's Encrypt CA comme ayant une chaîne de confiance expirée.

Voir plus d'informations sur les chaînes de confiance actuellement émises sur Let's Encrypt.

La plupart des bundles de confiance de certificats CA à jour, tels que fournis par les systèmes d'exploitation, contiennent ce certificat qui arrive bientôt à expiration. Les ensembles de certificats CA actuels contiennent également un certificat auto-signé ISRG Root X1. Cela signifie que les clients vérifiant les chaînes de certificats peuvent trouver le chemin alternatif non expiré vers le certificat auto-signé ISRG Root X1 dans leur magasin de confiance.

Malheureusement, cela ne s'applique pas à OpenSSL 1.0.2 qui préfère toujours la chaîne non fiable et si cette chaîne contient un chemin menant à un certificat racine de confiance expiré (DST Root CA X3), il sera sélectionné pour la vérification du certificat et l'expiration sera être signalé.

Voici quelques solutions de contournement possibles pour résoudre le problème :


Solution de contournement 1 (sur les clients avec OpenSSL 1.0.2)

Supprimez simplement le certificat racine expiré (DST Root CA X3) du magasin de confiance utilisé par le client OpenSSL 1.0.2 TLS pour vérifier l'identité des serveurs TLS. Si le nouveau certificat auto-signé ISRG Root X1 n'est pas déjà dans le magasin de confiance, ajoutez-le.

Il n'y a aucun inconvénient à cette solution de contournement, à l'exception de la nécessité de modifier tous les magasins de confiance potentiels des hôtes OpenSSL 1.0.2 TLS clients.

La suppression et l'ajout de certificats depuis/dans les magasins de confiance de certificats système est une opération très spécifique selon le système d'exploitation. Par exemple, sur les systèmes basés sur Linux qui gèrent les magasins de confiance de certificats système avec l'outil ca-certificates, un certificat CA peut être supprimé en copiant d'abord le certificat dans le /etc/pki/ca-trust/source/blacklistrépertoire et ajouté en le copiant dans le fichier /etc/pki/ca-trust/source/anchors directory. Le magasin de confiance est ensuite mis à jour en exécutant la update-ca-trustcommande.


Solution de contournement 2 (sur les clients avec OpenSSL 1.0.2)

La -trusted_firstprise en charge de l'option dans openssl verify, openssl s_client, et d'autres commandes openssl similaires, lorsqu'elles sont appliquées, remplace la construction de la chaîne de certificats et préfère donc les certificats du magasin de confiance aux certificats non approuvés dans la chaîne fournie par l'homologue. Cela signifie effectivement qu'avec l'option activée, le problème ne se produit pas.

Cependant, l'option n'est pas activée par défaut et les applications tierces ne permettent généralement pas d'activer cette option. Les applications devraient appeler la fonction X509_VERIFY_PARAM_set_flags() avec le drapeau X509_V_FLAG_TRUSTED_FIRST pour activer cette option.

La prochaine version d'OpenSSL 1.0.2 (1.0.2zb - disponible uniquement pour les clients du support premium) permettra de construire la version avec l'ajout -DOPENSSL_TRUSTED_FIRST_DEFAULT sur la ligne de commande de configuration de construction. Cela rendra l'option -trusted_first activée par défaut par la bibliothèque OpenSSL.


Solution de contournement 3 (sur les serveurs auxquels les clients 1.0.2 se connectent)

Configurez le serveur pour utiliser la chaîne de certificats alternative qui peut être demandée à Let's Encrypt avec la plupart des clients du protocole ACME à jour. Cette chaîne ne contient pas la racine ISRG X1 signée par la racine DST CA X3 bientôt expirée et ainsi aucun client OpenSSL 1.0.2 ne sera induit en erreur par ce chemin expiré.

L'inconvénient est que les serveurs seront considérés comme utilisant un certificat racine non approuvé par certains clients Android plus anciens, car ces clients ne contiennent pas le certificat ISRG Root X1 auto-signé dans leurs magasins de confiance.


Source : Blog OpenSSL, par Thomas Mraz, le 13 septembre 2021

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #81 le: 27 septembre 2021 à 08:45:57 »
Let's Encrypt en parle également et demande à passer à OpenSSL 1.1.0 :

Expiration du certificat racine DST Root CA X3 en septembre 2021

Le 30 septembre 2021, il y aura un petit changement dans la façon dont les anciens navigateurs et appareils font confiance aux certificats Let's Encrypt. Si vous exploitez un site Web classique, vous ne remarquerez pas de différence - la grande majorité de vos visiteurs accepteront toujours votre certificat Let's Encrypt. Si vous fournissez une API ou devez prendre en charge des appareils IoT, vous devrez peut-être accorder un peu plus d'attention au changement.

Let's Encrypt possède un « certificat racine » appelé ISRG Root X1 . Les navigateurs et appareils modernes font confiance au certificat Let's Encrypt installé sur votre site Web car ils incluent ISRG Root X1 dans leur liste de certificats racine. Pour nous assurer que les certificats que nous émettons sont fiables sur les appareils plus anciens, nous avons également une « signature croisée » à partir d'un ancien certificat racine : DST Root CA X3.

Lorsque nous avons commencé, cet ancien certificat racine (DST Root CA X3) nous a aidés à démarrer et à être immédiatement approuvés par presque tous les appareils. Le nouveau certificat racine (ISRG Root X1) est désormais largement approuvé - mais certains appareils plus anciens ne le feront jamais car ils ne reçoivent pas de mises à jour logicielles (par exemple, un iPhone 4 ou un HTC Dream). Cliquez ici pour obtenir une liste des plates-formes qui font confiance à ISRG Root X1 .

DST Root CA X3 expirera le 30 septembre 2021. Cela signifie que les appareils plus anciens qui ne font pas confiance à ISRG Root X1 commenceront à recevoir des avertissements de certificat lorsqu'ils visiteront des sites qui utilisent des certificats Let's Encrypt. Il y a une exception importante : les anciens appareils Android qui ne font pas confiance à ISRG Root X1 continueront à fonctionner avec Let's Encrypt, grâce à un signe croisé spécial de DST Root CA X3 qui s'étend au-delà de l'expiration de cette racine. Cette exception ne fonctionne que pour Android.

Que faire? Pour la plupart des gens, rien du tout ! Nous avons configuré notre émission de certificats pour que votre site Web fasse ce qu'il faut dans la plupart des cas, favorisant une large compatibilité. Si vous fournissez une API ou devez prendre en charge les appareils IoT, vous devrez vous assurer de deux choses :
(1) tous les clients de votre API doivent faire confiance à ISRG Root X1 (pas seulement DST Root CA X3)
(2) si les clients de votre API utilisent OpenSSL, ils doivent utiliser la version 1.1.0 ou ultérieure . Dans OpenSSL 1.0.x, une bizarrerie dans la vérification des certificats signifie que même les clients qui font confiance à ISRG Root X1 échoueront lorsqu'ils seront présentés avec la chaîne de certificats compatible Android que nous recommandons par défaut.


Source : Documentation Let's Encrypt, le 7 mai 2021.

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 636
  • Chambly (60)
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #82 le: 27 septembre 2021 à 09:21:45 »
OpenSSL en tant que client uniquement, non ?
La plupart du temps, c'est effectivement le client qui vérifie les certificats.
On peut faire de l'authentification mutuelle, où le client envoie aussi un certificat, qui est donc vérifié par le serveur. Mais c'est un usage particulier, qui n'a pas vraiment de sens avec Let's Encrypt.

OpenSSL n'est pas utilisé par les principaux navigateurs, sauf en embarqué (un WebKit actuel sous Linux, que ce soit WebKitGtk ou WPE, utilise soit GnuTLS, soit OpenSSL, mais le premier dépend d'une librairie LGPLv3).
En revanche, il sert dans beaucoup de programmes ou librairies, par exemple curl (qui peut aussi utiliser d'autres librairies, comme GnuTLS ou NSS).

vivien

  • Administrateur
  • *
  • Messages: 39 445
    • Twitter LaFibre.info
2021: Android 7 et antérieures ne feront plus confiance à Let's Encrypt
« Réponse #83 le: 27 septembre 2021 à 09:35:42 »
J'ai trouvé un cas où cela devrait poser problème : Le téléchargement des mises à jour de sécurité pour Ubuntu 14.04 LTS et Ubuntu 16.04 LTS.
Le support de ces distributions sont assurés pendant 10 ans, avec l'Ubuntu Advantage subscription (gratuit pour un usage personnel).

La version d'OpenSSL n'est pas et ne sera mis à jour en OpenSSL version 1.1.0 ou ultérieure (les patchs de sécurité sont backporté dans OpenSSL 1.0.2).

Les mises à jour sont téléchargées https://esm.ubuntu.com/ (c'est bien du https par défaut qu'utilise apt-get pour ce dépôt)

Vous voulez voir avec quel certificat est utilisé par les dépots de mise à jour de sécurité ? C'est Let's Encrypt !



La solution ? Faire les mises à jour pendant le fenêtre où c'est possible : entre le 23 septembre et 30 septembre 2021

Pour ne pas casser les certificats qui n'auraient pas intégrés ISRG Root X1, la suppression du certificat racine expiré DST Root CA X3 du magasin de confiance utilisé par le client OpenSSL 1.0.2 n'a été proposé en tant que mise à jour de sécurité que le 23 septembre 2021 pour Ubuntu, ce qui laisse une semaine pour faire les mises à jour et éviter le blocage des mise à jour et d'autres choses.

Si vous avez OpenSSL 1.0.2, il est donc très important de faire toutes les mises à jour de sécurité avant le 30 septembre.



Le certificat racine expiré DST Root CA X3 est supprimé pour toutes les versions d'Ubuntu :