Journal Certificat expiré

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
16
1
oct.
2021

Bonjour tout le monde,

C'est un journal que j'ouvre en rapport avec l'expiration du certificat IdentTrust DST Root ÇA X3 qui a eu lieu hier vers 16h heure française si ma mémoire est bonne.

Mais voilà aujourd'hui en voulant me rendre sur mon site préféré linuxfr voilà que la passerelle de sécurité à mon travail m'annonce qu'il y a un problème avec le certificat du site et qu'il n'est plus de confiance. Je teste d'autres sites et même résultat avec zdnet.fr ou aqualizr.com par exemple.

Du coup je contacte mon service informatique qui me répond que le problème ne vient pas d'eux mais des sites en question qui n'ont pas de certificat valide…

J'émets de sérieux doutes sur cette réponse sachant que je n'ai aucun soucis pour accéder à ces sites depuis une connexion Internet "normale".

J'ai plutôt de sérieux doutes sur la passerelle qui sécurise la navigation sur Internet.

Si quelqu'un aurait une réponse ou mieux un administrateur du site qui pourrait me certifier (sans jeu de mot :) ) que tout va bien histoire de pouvoir recontacter mon service informatique avec quelques billes dans la poche.

Merci d'avance.

  • # Envoies leur ce lien ?

    Posté par  . Évalué à 3.

    https://www.futura-sciences.com/tech/actualites/technologie-sont-ordinateurs-smartphones-ne-pourront-plus-connecter-internet-30-septembre-93772/

    Si ils ne captent pas, à défaut de renouveler le certificat, je te propose de penser à renouveler les admins :p

  • # L’explication officielle

    Posté par  (site web personnel) . Évalué à 6.

    L’explication officielle est ici : https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

    Si votre proxy web est à la ramasse dans ses updates (OpenSSL / le trust-store), ça va effectivement se vautrer. J’ai dû bricoler des Ubuntu 14 à ce sujet (simplement supprimer le DST Root CA X3).

    • [^] # Re: L’explication officielle

      Posté par  . Évalué à 1.

      Oui c'est ce que je pensais aussi. J'avais vu l'article sur leur site. Ce même site qui ne fonctionne d'ailleurs pas depuis la travail. Là j'avoue que j'ai bien ri :D

  • # Commentaire supprimé

    Posté par  . Évalué à 8.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Ils ont à moitié raison

      Posté par  . Évalué à 3.

      Ahah excellent tourné comme ça. +1

    • [^] # Re: Ils ont à moitié raison

      Posté par  . Évalué à 2. Dernière modification le 03 octobre 2021 à 00:25.

      Edit: Désolé, j’avais mal lu ton commentaire, tu dis la même chose que moi (le problème est côté client).

      Y a pas vraiment de mise à jour à faire côté serveur, les certificats présentés sont correctes et même si ISRG Root X1 est signé par DST Root CA X3 (expiré), un client à jour devrait pouvoir construire une chaine valide.

      Ensuite, s’il y a des gens qui étaient en mesure de « mettre à jour » c’était Let’s Encrypt.

      La plupart des gens utilisent Let’s Encrypt avec des outils qui automatisent tout pour eux, LE aurait pu décommissionner la version de ISRG Root X1 signé par DST Root CA X3 plus tôt.

      Pour rappel, un site avec un certificat Let’s Encrypt va présenter la chaine suivante :

      `CN = example.com`, signé par `C = US, O = Let's Encrypt, CN = R3`
  → `C = US, O = Let's Encrypt, CN = R3` signé par `C = US, O = Internet Security Research Group, CN = ISRG Root X1`
    → `C = US, O = Internet Security Research Group, CN = ISRG Root X1` signé par `O = Digital Signature Trust Co., CN = DST Root CA X3`

      DST Root CA X3 n’est pas présenté par le serveur mais est présent dans les magasin de certificats.

      ISRG Root X1 quant à lui, en plus d’être signé par DST Root CA X3 est présent sur tous les périphérique et navigateur à jour depuis au moins 5 ans et les version openssl supérieur ou égale 1.1.0 sont capable de construite une chaine valide avec ça.

      Le problème ici, c’est qu’une partie des applications (pas à jour) va continuer à construire la chaine jusqu’à DST Root CA X3 et ne pas la valider parce que ce certificat est expiré.

      Une solution pour corriger ce problème (qui ne devrait pas en être un) c’est de retirer ISRG Root X1 de la liste des certificats présentés par le serveur et tout rentra dans l’ordre pour les clients qui l’ont dans leur magasin de certificats.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Ils ont à moitié raison

        Posté par  (site web personnel) . Évalué à 0. Dernière modification le 15 novembre 2021 à 16:47.

        DST Root CA X3 n’est pas présenté par le serveur mais est présent dans les magasin de certificats.

        C'est pas tout à fait exact, il est référencé en tant que signataire de "ISRG Root X1", quand tu récupères ton certificat auprès de letsencrypt il contient trois sections.

        La première section contient ton certificat émis par "C = US, O = Let's Encrypt, CN = R3"

        Puis une seconde section contient le certificat "C = US, O = Let's Encrypt, CN = R3" émis par "C = US, O = Internet Security Research Group, CN = ISRG Root X1"

        Enfin une troisième section contient le certificat "C = US, O = Internet Security Research Group, CN = ISRG Root X1" émis par "O = Digital Signature Trust Co., CN = DST Root CA X3"

        Tu te retrouves coincé par les clients qui font pas confiance à "ISRG Root X1" ou tente de valider le certificat présenté en troisième section signé par "DST Root CA X3" qui est expiré.

        Pour comment supprimer la troisième section, voir mon commentaire plus bas.

  • # Ca veux dire aussi que c'est une passerelle ...

    Posté par  . Évalué à 4.

    qui déchiffre/rechiffre les sites que tu visites ?

    • [^] # Re: Ca veux dire aussi que c'est une passerelle ...

      Posté par  . Évalué à 1.

      C'est la fameuse passerelle. Donc pour moi ça ne fait pas de doute que le problème vient de là.

    • [^] # Re: Ca veux dire aussi que c'est une passerelle ...

      Posté par  . Évalué à 2.

      Ça se passe comme ça en entreprise car ils veulent s'assurer qu'aucune information ne fuite et/ou que les moyens informatiques ne sont pas utilisés pour qqch d'illicite.
      En plus ça se fait en douce car la CA interne est déployée sur les postes donc le navigateur maison (souvent edge ou chrome) ne se plaint pas.
      Mieux vaut utiliser un navigateur installé à part (FF portable par ex) et ne pas faire de navigation non pro et éviter le bancaire en particulier car le flux est en clair sur des machines accessibles aux admins.

  • # TLS or not TLS

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 01 octobre 2021 à 16:36.

    la passerelle de sécurité à mon travail

    "Passerelle de sécurité", la douce oxymore.

    Joli mot pour désigné une grosse ignobilie qui ouvre du trafique sécurisé en faisant des attaques man in the middle sur TLS via un proxy et des certificats installés de force sur les machines clientes.

    Ce genre de connerie est un trou de sécurité béant, un non-sens complet dans une politique de sécurité en 2021.

    Ce sont les managers de tes sysadmins et leur consultants (ceux qui ont mis ça en place) qu'il faudrait brûler.

    Cordialement

    • [^] # Re: TLS or not TLS

      Posté par  (site web personnel) . Évalué à 3.

      J'aime bien les avis nuancés comme le tien, qui prennent notamment en compte que le cas présenté est peut-être particulier :)

      • [^] # Re: TLS or not TLS

        Posté par  (site web personnel) . Évalué à 5.

        compte que le cas présenté est peut-être particulier :)

        Il n'y a aucun cas particulier où ce genre d'aberration peut être justifié.

        • Soit l'environnement est considéré comme critique (armée, banque) et le poste client n'a rien à faire connecté à internet.

        • Soit il n' ai pas critique et ce genre de pratique n'a aucune raison d'être.

        • [^] # Re: TLS or not TLS

          Posté par  . Évalué à 6.

          Autant je suis pour un internet neutre, libre t respectueux de la vie privée.
          Autant, en entreprise, l'informatique est un outil de travail.
          Si l'entreprise estime devoir se protéger de fuite d'information ou d'usage illicite, c'est son droit. Elle est responsable devant la justice de cet usage.

          Leur seul devoir est d'en informer l'employé et c'est peut être là que ça pêche. Car - alors que je côtoie un public d'informaticiens - peu d'employés ont conscience que l'entreprise voit tout le trafic.

          Tu veux faire du perso, ne le fais pas avec un pc de boulot.

          • [^] # Re: TLS or not TLS

            Posté par  . Évalué à 2.

            D'autant plus que c'est la responsabilité de l'entreprise de te fournir ton environnement de travail.

            Il est humainement impossible pour les administrateurs système de maîtriser parfaitement toutes les subtilités de tous les postes, logiciels et librairies associées.

            Partant de là, je peux comprendre que certains souhaitent avoir la main sur la certification pour pouvoir (au moins de manière temporaire le temps de déployer un correctif acceptable) bypasser des contraintes techniques.

            Matricule 23415

            • [^] # Re: TLS or not TLS

              Posté par  (site web personnel) . Évalué à 9.

              Il est humainement impossible pour les administrateurs système de maîtriser parfaitement toutes les subtilités de tous les postes, logiciels et librairies associées.

              Du coup on mets en place un proxy pourri qui rends humainement impossible pour administrateurs système de maîtriser parfaitement toutes les subtilités de leurs postes, logiciels et librairies associées.

              Sauf qu'en plus ce proxy rends humainement pénible aux utilisateurs d'utiliser parfaitement leurs postes, logiciels et librairies associées.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: TLS or not TLS

                Posté par  . Évalué à 3.

                Du coup on mets en place un proxy pourri qui rends humainement impossible pour administrateurs système de maîtriser parfaitement toutes les subtilités de leurs postes, logiciels et librairies associées.

                Je ne suis pas certain d'avoir compris. C'est pas le même admin que précédemment ?

                La fois où j'ai demandé à être admin de mon poste dans une grosse structure, ça a été accepté par tolérance (comme bien souvent par ailleurs dans des structures plus petites) mais j'ai été isolé dans un réseau spécifique pour ces cas de figure, et je n'avais pas à demander trop d'aide des admins des machines utilisateur. Le paquet de contraintes allait avec le lot de facilités.

                Je ne dis pas que c'est super ces proxys, ça peut être une solution non idéale pratique. Et en matière de pas pratique pour travailler, j'ai vu bien pire niveau sécurité.

                Matricule 23415

        • [^] # Re: TLS or not TLS

          Posté par  . Évalué à 1.

          Soit l'environnement est considéré comme critique (armée, banque) et le poste client n'a rien à faire connecté à internet.

          C'est exactement ça.

          Le poste de travail n'est pas connecté à internet. Essaye un ping fr.wikipedia.org, ça ne marchera pas.

          C'est le proxy qui est connecté à internet et qui est chargé de délivrer un contenu filtré selon les politiques de l'entreprise à l'utilisateur.

          Je ne vois pas d'aberration là dedans.

          • [^] # Re: TLS or not TLS

            Posté par  (site web personnel) . Évalué à 10. Dernière modification le 03 octobre 2021 à 16:18.

            C'est le proxy qui est connecté à internet et qui est chargé de délivrer un contenu filtré selon les politiques de l'entreprise à l'utilisateur.

            Je ne vois pas d'aberration là dedans.

            • Soit le proxy est configuré sur du whitelisting-only ET sur un subset de service / addresse Cloud bien définis, nécessaire à l'entreprise et tout le reste est bloqué: c'est défendable.

            • Soit comme trop souvent, c'est juste là pour faire du Man-in-the-middle et le traffic HTTP/HTTPS est en open bar sur (presque) tout internet. Ça sert uniquement à ouvrir le traffic HTTPS et bloquer tout le reste: Et C'est c'est complètement con

            1- Ça crée un bottleneck sur le trafique dans l'entreprise car tout le contenu HTTP/HTTPS sortant passe par là.

            2- Ça crée un point de vulnérabilité gigantesque dans l'entreprise car toute personne qui prend le contrôle du proxy peut "ouvrir" le trafique et accéder aux logins / mots de passe de tout le monde, incluant même les second facteurs.

            3- Ça rend excessivement chiant l'utilisation de tout logiciel qui utilise du trafique non-HTTP (Vidéo conférence, Messaging, client Email lourd, VPN ) et ça fait souvent buguer une bonne partie des sites web qui utilisent les Web Sockets.

            4- C'est un faux argument de sécurité, car je peux te donner 20 manière d'exfiltrer des données en overlay sur du HTTPS et ni ton proxy ni toi n'y verront rien du tout.

            5- A l'opposé, la majorité des malwares aujourd'hui n'ont aucun problème à bypasser ça.

            Donc oui je réitère ce que j'ai dit: c'est complètement con.

            C'est un théâtre de sécurité périmétrique qui réduira la productivité de vos utilisateurs sans fournir la moindre protection contre les attaques modernes ( crypto-lockers, phishing, social-engineering, etc ).

            Nous sommes en 2021, la sécurité périmétrique est morte et enterrée. Apprenez à faire avec.

            • [^] # Re: TLS or not TLS

              Posté par  . Évalué à 1.

              Ce n'est pas un bottleneck car en général, c'est le lien internet qui l'est : les machines ont facilement X fois 40Gbps, internet est à 10Gbps

              Nous sommes en 2021, la sécurité périmétrique est morte et enterrée. Apprenez à faire avec.

              Pour protéger un SI oui. Là on parle d'empêcher Jean-Michel d'aller sur 'cutekitty.net' avec son pc pro.

              • [^] # Re: TLS or not TLS

                Posté par  (Mastodon) . Évalué à 4. Dernière modification le 04 octobre 2021 à 08:40.

                Ffaire du man in the middle ne l'empêche pas.

                D'ailleurs la plupart de ces setups n'empêchent rien, ils ne font que logger et permettre l'analyse sur demande.

            • [^] # Re: TLS or not TLS

              Posté par  . Évalué à 6.

              2- Ça crée un point de vulnérabilité gigantesque dans l'entreprise car toute personne qui prend le contrôle du proxy peut "ouvrir" le trafique et accéder aux logins / mots de passe de tout le monde, incluant même les second facteurs.

              Surtout quand le proxy en question est acheté par un décideur préssé : https://www.bortzmeyer.org/killed-by-proxy.html

  • # SSL Certificate Errors

    Posté par  (site web personnel) . Évalué à 5.

    Tu connais le nom de ta passerelle (firewall) ?

    Si c'est un Fortinet en mode proxy, il y a un souci : SSL Certificate Errors

  • # Exemples

    Posté par  (site web personnel) . Évalué à 3.

    (…) mon site préféré linuxfr (…) à mon travail (…) zdnet.fr (…) aqualizr.com

    Peut-être qu'il vaudrait mieux leur donner un autre exemple de site qui ne passe pas?

    Un LUG en Lorraine : https://enunclic-cappel.fr

  • # Liste des services touchés

    Posté par  (site web personnel) . Évalué à 3.

    Dans un article de ZDNet on trouve une liste de services et prestataires touchés.

    Scott Helme confirme à ZDNet qu'il a repéré des problèmes avec Palo Alto, Bluecoat, Cisco Umbrella, Catchpoint, Guardian Firewall, Monday.com, PFsense, Google Cloud Monitoring, Azure Application Gateway, OVH, Auth0, Shopify, Xero, QuickBooks, Fortinet, Heroku, Rocket League, InstaPage, Ledger, Netlify et Cloudflare Pages. Il ajoute qu'il pourrait y en avoir d'autres.

  • # Chaîne intermédiaire

    Posté par  . Évalué à 7.

    Ouais, ce problème est un peu relou. Surtout, il dépend énormément de la chaîne de certificats intermédiaires transmise par le serveur, et de la lib TLS côté client qui fait la vérification. Pour certains clients ACME (tous ?), la chaîne intermédiaire par défaut inclue la racine de Let's Encrypt (ISRG Root X1), mais sous sa forme "cross-signed" par l'autorité DST Root CA X3 (celle qui a expiré hier)
    C'était fait comme ça pour que Let's Encrypt puisse être reconnu, le temps que sa propre autorité ISRG Root X1 (sous sa forme d'autorité, donc auto-signée) soit diffusée un peu partout.

    Maintenant, il y a plusieurs cas de figure. Pour certains clients, quand ils vérifient la chaîne, ils identifient le R3 (intermédiaire de Let's Encrypt), qu'il est bien signé par l'ISRG Root X1, et que ce ISRG Root X1 est bien présent dans leur magasin de confiance, et donc s'arrêtent là, sans remonter plus haut, la connexion marche, tout le monde est content.

    Mais d'autres clients n'ont pas ce comportement. Il trouvent bien le ISRG Root X1 dans la chaîne, mais comme il est signé par la DST Root CA X3, ils continuent la vérification, et remonte à l'autorité DST Root CA X3. Et comme le DST est expiré, boum, ça casse.

    Il faut donc d'une part que les magasins de certificats soient bien à jour sur les clients (pour qu'ils possèdent le ISRG Root X1), et que le serveur modifie sa chaîne d'intermédiaires pour ne plus présenter la forme signée par DST de l'ISRG Root X1.

    Mais en faisant ça, on perd bien sûr la validation sur les vieux appareils, qui n'ont pas l'ISRG dans leur magasin. Bref, aucune solution n'est idéale

  • # c'est la fête avec OpenSSL sous Windows

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 01 octobre 2021 à 19:59.

    Sous Windows, le nouveau certificat racine ISRG Root X1 (celui qui remplace DST Root CA X3) est ajouté à la liste des certificats de l'OS de manière lazy la première fois qu'il est utilisé.

    Le soucis c'est que seul l'implémentation de TLS fourni par l'api Windows (cad CertVerifyCertificateChainPolicy ) déclenche cette récupération !

    Concrètement ça veut dire que si tu utilises uniquement Firefox (qui embarque ses propres certificats racine et n'utilise pas l'api windows pour faire du TLS), et bien il y a toutes les chances que ton PC n'ait pas ISRG Root X1.
    Et du coup quand tu utilises OpenSSL avec les certificats du système (c'est ce que fait Python par default) tu te retrouves avec une belle erreur SSL ! (Python récupèrant les certificats auprès du système avant de les charger dans OpenSSL)

    Le plus beau étant que pour résoudre ça il suffit d'ailleurs sur n'importe quel site utilisant Let's Encrypt depuis Edge/IE/Chrome (ce qui va déclencher la récupération de ISRG Root X1).

    plus d'info:
    https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550
    https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/
    https://github.com/psf/requests/issues/2966#issuecomment-636750327

    Et comme vous êtes gourmand, petit bonus:
    Tous les certificats fournis par Let's Encrypt son signés par le certificat intermédiaire S3 qui est disponible signé par DST Root CA X3 et ISRG Root X1.
    Si il se trouve que par hasard vous avez le certificat intermédiaire S3 signé par DST Root CA X3 sur votre machine, alors c'est celui-ci qui sera utilisé (d'ailleurs si vous avez une idée pourquoi je suis preneur ) et provoquera une erreur:

    $ python -c "from urllib.request import urlopen; print(urlopen('https://linuxfr.org').status)"
Traceback (most recent call last):
[...]
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1131)>

    La solution ? Faire comme Firefox et embarquer ses propres certificats racines dans son application (mais du coup 1) incompatible avec ces "passerelles de sécurité" à moins de permettre un mécanisme de chargement de certifs additionnels et 2) obligé de mettre à jour l'application quand les certificats changent :'( )

    • [^] # Re: c'est la fête avec OpenSSL sous Windows

      Posté par  . Évalué à 1.

      ça marche!
      J'avais un problème de certificat SSL avec le client seadrive/seafile.
      J'utilise Firefox donc le pb demeurait.
      J'ai lancé chrome sur la version web seafile et le problème est résolu.

  • # macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

    Posté par  (site web personnel) . Évalué à 10.

    Hier je bossais sur le portage de l’éditeur de niveau NetRadiant sur macOS (il faudra que je fasse un jour un journal sur cette (més)aventure, c’est une véritable descente en enfer), et le petit coup de barre de fer dans les rotules à la date d’hier, le voici :

    2021-09-30 19:24:41 +0200 <illwieckz> it looks like I managed to properly workaround the lack of OpenGL context sharing on macOS GtkGLExt with NetRadiant
2021-09-30 19:26:06 +0200 <illwieckz> lol macos
2021-09-30 19:26:10 +0200 <illwieckz> [  0%] Performing update step for 'gtkglext'
2021-09-30 19:26:10 +0200 <illwieckz> fatal: unable to access 'https://gitlab.gnome.org/illwieckz/gtkglext.git/': SSL certificate problem: certificate has expired
2021-09-30 19:27:41 +0200 <illwieckz> exactly 1 minute [after] I get all features working on macos, I'm become unable to build the software because macos dediced a certificate is expired
[…]
2021-09-30 19:27:48 +0200 <illwieckz> fun fact, it is not expired on linux
2021-09-30 19:28:28 +0200 <illwieckz> it expires en December 19, 2021
2021-09-30 19:28:40 +0200 <illwieckz> OR
2021-09-30 19:28:49 +0200 <illwieckz> maybe the autority certificate expired
2021-09-30 19:28:58 +0200 <illwieckz> the one bundled in macOS
[…]
2021-09-30 19:29:52 +0200 <illwieckz> I'm impressed [by] how unforgiving it is
2021-09-30 19:30:00 +0200 <illwieckz> everytime I get a victory
2021-09-30 19:30:12 +0200 <illwieckz> I get smashed down
[…]
2021-09-30 19:35:39 +0200 <illwieckz> for safari the certificate isn't expired…
2021-09-30 22:25:11 +0200 <illwieckz> it's possible the root certificate are obsoletes
2021-09-30 22:25:48 +0200 <illwieckz> I'm using macOS Mojave
2021-09-30 22:25:58 +0200 <illwieckz> support ends in September 2021
2021-09-30 22:26:11 +0200 <illwieckz> we are like, the last day of September 2021
2021-09-30 22:27:59 +0200 <illwieckz> it's already October 1th since 9 hours in some places
2021-09-30 22:28:43 +0200 <illwieckz> on my end those certificates stopped working 3 hours ago
2021-09-30 22:30:40 +0200 <illwieckz> but it's still September in Cupertino
[…]
2021-10-01 00:32:20 +0200 <illwieckz> iMac-de-Thomas:macos-new illwieckz$ cat ~/.gitconfig
2021-10-01 00:32:20 +0200 <illwieckz> [http "https://gitlab.gnome.org"]
2021-10-01 00:32:20 +0200 <illwieckz>   sslCAInfo = /Users/illwieckz/lets-encrypt-r4-cross-signed.pem
2021-10-01 00:32:20 +0200 <illwieckz>   sslVerify = true
2021-10-01 00:32:52 +0200 <illwieckz> this is the way I worked around the macos letsencrypt bug for cloning from gitlab.gnome.org

    À la base j’ai cette installation de macOS pour travailler sur le port de NetRadiant sur macOS, maintenant j’en profite aussi pour compiler Unvanquished pour macOS, mais à la base, je n’avais cette installation de macOS que pour réaliser ce portage de NetRadiant. Je travaille sur ce portage de NetRadiant depuis 2018 au moins, et c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne » et c’est toujours un macOS Mojave, il à jour de macOS et de Homebrew, mais j’ai pas monté les versions majeures depuis que je bricole avec.

    Et hier, le certificat racine IdentTrust DST Root ÇA X3 a expiré, et macOS Mojave considère désormais tous les certificats LetsEncrypt comme périmés, je ne peux donc plus cloner de dépôts depuis les forges gnome.gitlab.org ou sourceforge.net.

    Le truc c’est qu’à ce que j’ai compris, la fin de la prise en charge de macOS Mojave prend fin… ce premier octobre. Apple n’est donc probablement pas engagé à mettre à jour les certificats racines de macOS. J’ai essayé de le faire avec leur outil « trousseau » mais ajouter les certificats racines de LetsEncrypt et dire à macOS de leur faire confiance ne change rien. Techniquement, macOS Mojave a été en défaut de certificat fonctionnel une demi journée environ (selon le fuseau horaire) avant la fin de la prise en charge. Peut-être que chez Apple il s’est dit que ça n’en valait pas la peine.

    J’ai pu forcer le certificat racine de LetsEncrypt dans le fichier .gitconfig donc je vais pouvoir garder Mojave pour quelque temps encore…

    Bizarrement, Safari ne râle pas, il a probablement son propre trousseau (comme Firefox qui ne râle pas non-plus), mais les outils systèmes (y compris curl qui fait partie du système de base) ne peuvent plus discuter avec des sites utilisant un certificat LetsEncrypt.

    L’expiration de ce certificat racine qui arrive pile au moment de la fin de prise en charge de macOS Mojave rend « la fin du support » super brutale. Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet. ¯\_(ツ)_/¯

    Bref, si ça vous arrive, pour git vous téléchargez par exemple un certificat racine depuis cette page: https://letsencrypt.org/certificates/

    (cd ~ ; wget https://letsencrypt.org/certs/isrgrootx1.pem )

    Puis vous l’ajoutez dans votre fichier .gitconfig, par exemple:

    cat >> ~/.gitconfig <<EOF
[http "https://gitlab.gnome.org"]
  sslCAInfo = ${HOME}/isrgrootx1.pem
  sslVerify = true
EOF

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

      Posté par  (site web personnel) . Évalué à -4. Dernière modification le 02 octobre 2021 à 12:11.

      Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet. ¯_(ツ)_/¯

      En fait non, tu le dis toi-même :

      Bizarrement, Safari ne râle pas

      Et sérieusement, parler de "ne parle déjà plus à la moitié d’Internet" alors que ce qui est utilisé à 99.999% des gens marche encore, c'est juste agrandir un problème mineur très localisé. Surtout quand on dit ensuite :

      J’ai pu forcer le certificat racine de LetsEncrypt dans le fichier .gitconfig donc je vais pouvoir garder Mojave pour quelque temps encore…

      Bref, ça reste un problème mineur, rapidement corrigeable, et tu peux toujours utiliser le vieil OS. 0.001% (utilisateurs de cURL) de 10% (utilisateurs de vielle version, edit j'avais mis trop bas au départ certes) des utilisateurs de Mac qui doivent passer un peu de temps à adapter leur environnement. Rien de rude.

      (comme Firefox qui ne râle pas non-plus),

      Pour Firefox c'est normal ils ont choisi depuis longtemps et sur tous les OS d'avoir leur propre magasin de certificats pour ne pas dépendre de l'OS qu'ils ne contrôlent pas.

      Sinon, Ce qui aurait été intéressant si quelqu'un a la motivation d'avoir l'explication sur pourquoi le navigateur d'Apple (qui contrôle l'OS) accepte et pas les outils en ligne de commande, des "chemins" de validations différents? Ca a l'air bien compliqué suivant les logiciels et les versions de logiciels de savoir quel "chemin" est pris en priorité et/ou si les autres "chemins" sont pris en cas où le "chemin" principal ne marche pas…

      c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne »

      Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom). Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.

      • [^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

        Posté par  (site web personnel) . Évalué à 10.

        Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet.

        En fait non, tu le dis toi-même :

        Bizarrement, Safari ne râle pas

        Tu confonds Web et Internet. 🤦‍♀️

        c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne »

        Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom). Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.

        Parfois c’est assez incroyable de voir comment tu peux aller loin dans l’imaginaire.

        Je rappelle le contexte :

        • un système qui n’est prévu que pour faire le portage d’un logiciel vers macOS (machine de build) et qui accessoirement est devenu aussi l’environnement de compilation d’un autre logiciel pour macOS (machine de build), je l’ai précisé dans mon commentaire.
        • un système qui est à jour de macOS et de son environnement de développement spécifique (incluant le compilateur fourni par Apple ainsi que les bibliothèques et outils installés via Homebrew, ici), je l’ai précisé dans mon commentaire, et qui est même encore pris en charge au moment des faits, je l’ai précisé dans mon commentaire.
        • un système dont j’ai le contrôle (ça semble assez évident vu la façon dont j’ai tourné mon commentaire)

        Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom).

        Ici le système macOS a le rôle d’un docker qui est démarré pour faire un build et être éteint après, tu crois vraiment qu’il y a une « tonne de gens » qui « pensent ça dans un tel contexte et à qui « ça pose des problèmes de sécurité plus tard ». Tu n’as même aucune idée de l’isolement du système en question… Et pour rappel, les outils du système qui communiquent avec l’extérieur sont à jours, le seul truc pas à jour c’est un certificat racine que je peux ajouter.

        En fait je ne le précise pas mais depuis précisément le 30 septembre 2021, j’ai migré ce système depuis un bridge ouvert à mon LAN vers un réseau qui ne communique qu’entre ma machine principale et ce système de build et rien d’autre. La système ne sert à rien d’autre (pour tout dire, c’était peut-être la première fois en trois ans et depuis l’installation de macOS que j’utilisais le Safari que j’ai utilisé pour vérifier si le certificat fonctionnait). En dehors de deux dépôts (dont celui cité dans mon message initial) dont le clonage est réalisé par CMake, le clonage de dépôts (il y a peut-être une 20aine de dépôts) sont réalisés par la machine principale non-macOS qui orchestre les builds. En gross j’ai un script sous Linux que j’appelle en faisant quelque chose comme « ./do macos », et hop 95% des sources sont téléchargées sous Linux, le système macOS compile les sources (et clone lui-même deux dépôts qui font exception et dont un seul dépôt est un dépôt de code, hébergé par GNOME et dont je suis l’unique mainteneur de la branche utilisée), et hop ça recrache un build pour macOS.

        Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.

        Hors sujet, donc, puisque l’on parle de mes outils de ma propre entité. Tu imagines une situation fictive qui ne se produit pas.

        En fait, si tu veux me voir conspuer une entité pour ne pas avoir mis à jour ses outils et que ça m’a posé ensuite un problème, tu peux citer Apple et le fait de ne pas avoir mis à jour ses certificats racines pendant la durée de prise en charge de son système (haha).

        Bref, tu ne me connais pas, tu ne connais pas mes méthodes de travail, tu ne connais même pas mon opinion sur le sujet et tu n’as aucun moyen de le déduire de mon commentaire. Là je parle d’un cas très particulier d’un système dédié au build d’un logiciel qui est entretenu dans un environnement finement contrôlé. Tu ne peux rien déduire de ma politique dans d’autres situations. Dans d’autres contextes, je suis connu pour être l’ayatollah de la mise à jour et je peux pas te dire le nombre d’argumentaires que j’ai détruit de la part de personnes qui mettaient en danger des parcs informatiques entier, et je peux te dire que certains peuvent témoigner qu’il ne faut pas rigoler avec ça avec moi. Mais on n’est pas du tout dans ce contexte, c’est assez explicite normalement. C’est assez dingue comment tu te laisses dérouler ton imaginaire super loin en dehors du contexte en extrapolant de façon incroyable sur d’autres contextes qui sont de ta fabrication dans ta tête. En fait c’est normal d’explorer dans sa tête le champ des possibles, ce qui n’est pas normal, c’est de répondre non-pas au message et à la situation de ton interlocuteur, mais d’adresser à ton interlocuteur une réponse qui s’applique au monde que tu as créé dans ta tête, de faire subir aux autres tes réactions à des peurs correspondant à des situations fictives que tu as forgées dans ta tête.

        Tu aurais pu par exemple écrire (ça aurait été légitime) : « j’espère que tu n’appliques pas cette méthode dans d’autres contextes […] » et de rappeler avec raison que dans d’autres contextes ceci cela patati patata… En plus tu n’aurais pas pris un ton de reproche, tu aurais laissé à l’autre la liberté de se corriger s’il était dans l’erreur, avec même la possibilité de ne pas seulement élever le débat mais peut-être même élever la personne, et tu aurais simplement enseigné au lieu de condamner.

        Si tu veux plus de contexte, Je travaille sur ce portage depuis 3 ans. J’ai installé le système macOS Mojave à cette intention, et tout le développement s’est fait sur ce système alors qu’il était officiellement maintenu, en faisant toutes les mises à jour, et comparant les comportements avec des snapshots réalisés avant mis à jour lorsque je rencontrais des problèmes après mis à jour, ce afin d’identifier les causes des régressions. Ce travail a été extrêmement douloureux pour diverses raisons que je ne peux pas décrire sans pondre un roman. Après trois ans, il ne me reste plus qu’un seul bug gênant qui m’empêche de publier la toute première version de l’histoire d’un éditeur de niveau entièrement compatible avec les technologies id Tech 3 et qui ne requiert pas XQuartz pour fonctionner. En fait, même la dernière version de MacRadiant qui doit dater de 2013 ou quelque chose comme ça nécessitait X11 sur macOS… Aucune autre alternative utilisant X11 n’est maintenue, et il n’existe pas d’alternative n’utilisant pas X11 qui soit complète (DarkRadiant ne gère toujours pas intégralement certains modes de projection de textures à la façon d’id Tech 3). Il s’agit pour moi de remplir un besoin qui n’est pas du tout satisfait, que j’ai fait uniquement par générosité parce que je pense que c’est important, qui plus est avec en face de moi une certaine ingratitude car les utilisateurs de macOS n’ont souvent pas idée du coût faramineux que peut impliquer un portage sur macOS, je dis bien peut car certains portages se font comme une lettre à la poste mais le cas que j’ai traité est probablement le plus incroyablement compliqué pour diverses raisons.

        Juste pour dresser un portrait vite-fait : Il y a 10 ans le logiciel utilisait GTK avec GtkGLExt, X11, OpenGL non-core et requiert de partager le contexte OpenGL entre plusieurs viewport, et ne gèrait évidemment pas le hiDPI à la sauce Apple. GTK2 est obsolète en général (GTK3 et GTK4 sont sortis), X11 est obsolète sur macOS d’Apple, OpenGL non-core est obsolète en général, OpenGL tout court est obsolète sur macOS d’Apple, GtkGLExt est obsolète (remplacé par GtkGLArea) mais il n’y a pas d’implémentation GtkGLExt pour macOS fonctionnelle sans X11 (elle n’a jamais été terminée), et il n’y a pas d’implémentation GtkGLArea pour OpenGL non-core dans GTK3 ni dans GTK4 pour maCOS d’Apple (donc si vous avez bien suivi, il n’y a officiellement aucune solution pour réaliser ce portage). Sous macOS avec ce logiciel la gestion du pointeur ne fonctionne pas correctement, ni le multi-écran, les surfaces OpenGL recouvertes par des surfaces non-OpenGL sont dessinées par dessus les surfaces non-OpenGL, et quand certains de ces problèmes ont des contournements. Et sous macOS le partage de contexte OpenGL n’est pas fonctionnel. Et pour Windows, le logiciel est même distribué avec une version de Mesa utilisable de manière optionnelle afin de contourner certains problèmes de drivers intégrés de Windows 10. Et aujourd’hui le code sait tourner sous Linux, Windows, macOS, FreeBSD et travailler avec GTK2, GTK3, GtkGLExt, GTKGLArea, OpenGL, X11 natif, Quartz natif, le-truc-de-windows natif, Wayland est en cours, implémente des contournement pour des bugs d’affichage dans Windows, implémente une palanquée d’autres contournements pour des bugs d’affichage dans macOS, des bugs de pointeurs dans macOS, sait travailler avec des contextes OpenGL partagés et non-partagés, et imite autant qu’il est raisonnable l’apparence native des applications du système Hôte (la version macOS respecte même la préférence d’environnement clair/foncé).

        Et bref, pour la première fois de l’histoire, après un travail de dingue de 3 ans et beaucoup d’arrachage de cheveux, je suis presque prêt à sortir pour macOS et de manière complètement bénévole la première version de l’histoire de ce logiciel. Le développement a duré toute la durée de vie de macOS Mojave. Alors oui, ça y est, Mojave est déprécié depuis hier venredi 1er octobre 2021 à ce que je crois, et bien tu sais quoi ? Il est complètement à jour à la date du 30 septembre 2021. Ce système est relativement isolé et ne sert qu’au build. Il est probable que je ne mette pas à jour macOS vers une version plus récente de Mojave avant la sortie de ce logiciel. Il n’y a plus qu’un bug gênant à résoudre et il sera prêt.

        Ce portage complètement bénévole m’a entre autre retardé dans la fusion d’un fork dont la masse accumulée (et qui continue de s’accumuler) de travail requise pour la fusion s’élève désormais à un nombre à 4 zéro si elle était évaluée en euro au salaire d’un développeur. Alors je veux terminer la version macOS d’abord, et je suis prêt à repousser un peu et sans rougir le moment où je devrais penser à l’après-Mojave.

        J’ai confirmation auprès d’utilisateur de macOS récents que la version compilée sous Mojave fonctionne sur les dernières versions de macOS. Alors tu sais quoi ? Je crois que d’ici à ce que je corrige ou contourne le dernier bug gênant, d’ici la publication de la note de version et la compilation finale du logiciel, je crois que je vais conserver mon système de build dans son environnement contrôlé et isolé et qui était à jour le 30 septembre 2021, vérifier moi-même les certificats si besoin un par un, publier cette première mondiale et de l’histoire, clore ce chapitre de douleur de trois ans, et peut-être, peut-être, envisager de tenter d’essayer de faire une mise à jour vers un macOS plus récent que Mojave et de voir si tout se passe bien. Après avoir publié le logiciel compilé sur un macOS à jour du 30 septembre 2021 et clôt un chapitre de 3 ans de souffrance, je pourrai peut-être envisager de prendre le risque d’ouvrir un nouveau chapitre de souffrance et de faire face à des problèmes dont la résolution est incertaine et implique une durée indéterminée de travail.

        Tu sais quoi ? à moins d’une découverte demain d’un exploit incroyable qui pourrait affecter de manière malicieuse la compilation d’un logiciel sur un environnement macOS à jour du 30 septembre 2021 de manière à véroler ce que produirait cet environnement de build, et/ou de briser au moins 3 pare-feux, et/ou de véroler le compilateur officiel d’Apple, soit en vérolant le source téléchargé via le dépôt de GNOME avec une communication vérifiée par un certificat Let's Encrypt dont j’ai validé l’autorité à la main, et/ou un accès physique en cassant le système de chiffrement de disque, je ne crois pas que je mettrais en danger qui que ce soit. En fait il serait peut-être plus raisonnable de penser à me menacer de me casser la gueule à grand coup de clé à molette (et même ça c’est pas sûr que ça marche), ou d’autres méthodes plus perverses. Il y a probablement plus de failles qui permettent de remonter jusqu’à ce système macOS ou de corrompre mes copies que de manière de faire produire du code vérolé par le compilateur d’Apple en faisant s’envoler un papillon. Par ailleurs le logiciel compilé ne fait aucune communication réseau donc je n’ai pas vraiment à m’inquiéter d’une faille dormante dans une bibliothèque de communication réseau par exemple. Une surface d’attaque réaliste serait par exemple une faille dans la libpng (ou autre format) pas encore découverte à la date du 30 septembre 2021, en supposant que quelqu’un arrive à refourguer une image vérolée (pour garder cet exemple) à un utilisateur du logiciel sous mac… Bref, le risque ne serait pas plus élevé qu’avec toute autre application publiée avant le 1er octobre 2021 même si compilée sur une version plus récente de macOS, tant que publié avant cette date.

        ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

      Posté par  (Mastodon) . Évalué à 1.

      GIT_SSL_NO_VERIFY=true

      curl -k

      • [^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

        Posté par  (site web personnel) . Évalué à 2.

        Il y a aussi git config --global http.sslVerify false ce qui écrit ceci dans ~/.gitconfig:

        [http]
    sslVerify = false

        Mais euh, non. 🛑 (← ceci est sensé représenter un panneau stop)

        Non, ça c’est vraiment un dernier recours, comme je l’ai indiqué il y a moyen de spécifier dans Git une autorité spécifique pour un serveur git en particulier. Et ça, on peut y faire confiance :

        [http "https://gitlab.gnome.org"]
  sslCAInfo = ${HOME}/isrgrootx1.pem
  sslVerify = true

        Avec la méthode que je donne, git continuera d’interrompre la connexion s’il y a un Man-In-The-Middle, alors qu’il ne le fera pas en désactivant la vérification, ce qui me rendrait vulnérable et donc par effet de bord, rendrait vulnérable les utilisateurs des logiciels que je compile éventuellement. J’imagine que la référence du commit de HEAD ne peuts probablement pas être falsifiée facilement (peut-être aussi difficilement que de faire un faux certificat qui marche, autrement dire, considéré comme raisonnablement difficile), mais j’ai pas envie de vérifier à la main à chaque clone.

        ce commentaire est sous licence cc by 4 et précédentes

  • # feu d'artifice et contournements

    Posté par  . Évalué à 5.

    J'ai eu pas mal de service impactés.
    En particulier tout ce qui utilise un curl avec un openssl pas assez récents.

    Les mises à jour n'ont pas toujours corrigé le problème.

    Pour certains j'ai du installer un curl statique. Pour d'autres j'ai téléchargé le .pem de la chaîne de certification dans le navigateur pour ensuite l'utiliser avec curl --cacert /path/to/pem. Cette seconde solution ne marchera que jusqu'à l'expiration du certificat (3 mois pour letsencrypt).

    • [^] # Re: feu d'artifice et contournements

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 02 octobre 2021 à 21:40.

      curl -k et il ne vérifie pas le certificat.

      (rien ne t'empêche de rajouter une ligne dans ton script qui vérifie avant avec openssl que le cert est bien vérifié avec le certificat racine que tu utilises)

      Là où c'est plus chiant, c'est pour les softs qui ont un système de maj interne et qui utilisent les certs du framework embarqué. Ma boite développe entre autre une application qui utilise electron mais comme la maj n'étaient jamais forcée ils se retrouvent avec des gens qui s'y prennent trop tard et dont la maj échoue. J'ai du acheter un certificat pour remplacer le lets encrypt pour que ça refonctionne.

      Bref on en fait des patacaisses pour rien.

      • [^] # Re: feu d'artifice et contournements

        Posté par  . Évalué à 5.

        curl -k

        Je suis pas fan. Demander à curl de ne pas vérifier le certificat, ça veut dire que si l'organisation se fait trouer, je m'en aperçois pas et peut me faire refourguer. Je préfère essayer de trouver un moyen pour qu'il valide le certificat. Je dirai que c'est en dernier recours et pour une utilisation ponctuelle, en CLI, pas dans un service qui tourne tout seul tout le temps.

        • [^] # Re: feu d'artifice et contournements

          Posté par  (Mastodon) . Évalué à 6.

          Si tu avais lu mon commentaire en entier, tu aurais vu que je parle de vérifier avant l'authenticité du certificat avec les certificats racines de ton choix via un client ssl.

          Accessoirement après avoir lu la manpage de curl, il est possible de fixer le chemin --capath donc n'importe qui peut utiliser les certificats racines de son choix.

  • # Des news

    Posté par  . Évalué à 2.

    J'ai de nouveau relancé le service concerné pour leur indiqué que NON ce ne sont pas les sites qui sont en défaut.
    J'ai donné un nouvel exemple, y a juste le site https://letsencrypt.org/fr/ qui sort la même erreur de problème de certificat et qui est donc bloqué par la passerelle.

    Plus qu'à attendre une réaction.

    • [^] # Re: Des news

      Posté par  . Évalué à 4.

      C'est bon tout est revenu à la normale.

      [TROLL]Heureusement que les milliers de sites concernés par ce problème ont fait une réunion ce matin afin de tous faire leur maj de certificats en même temps pendant la pause repas.[/TROLL]

      • [^] # Re: Des news

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Ben oui, tous les gens qui gèrent les sites concernés ont lu ton journal et se sont dit « bon sang mais c’est bien sûr » et ont mis à jour leur certificat. Tu vois une autre explication plausible ?

        Tu es un bienfaiteur de l’humanité internetienne en fait.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # raspbian

    Posté par  . Évalué à 1.

    Surpris par un impact inattendu …
    Mes Rapsberry (sous raspbian) sont tombés à cause de ce certificat.
    Seulement la connexion https de certains sites est tombée (et pas par terre) :)

    Alors que le nouveau certificat est bien présent, il tente d’utiliser l'ancien systématiquement, j'ai été obligé de le désactiver manuellement.

    Et quand tu en a dispersé dans toutes la France … c'est pas cool !

  • # K-9 Mail sur Android 7.0 et serveur de mail perso

    Posté par  (site web personnel) . Évalué à 0.

    Salut,

    Un commentaire plus haut m'a mis sur la piste d'un bug étrange rencontré sur mon téléphone.

    J'ai un petit serveur web, mail et autre avec un certificat letsencrypt renouvelé automatiquement.

    Pour ce qui est de la navigation web aucun problème à signaler avec un chrome plus ou moins à jour.

    Par contre petit problème avec l'application K-9 Mail qui s'est mise à jeter mon certificat serveur vu qu'un des certificats de la chaîne a expiré.

    J'ai fait sauter côté serveur le 3 ème bloc de certificat que fournit letsencrypt qui correspond au certificat "DST Root CA X3" expiré de toute façon.

    Dans mon client acme je supprime le premier double saut de ligne et retire ce qui suit le second double saut de ligne.

    Rapsys acme un client perl letsencrypt avec config json.

    Côté téléphone c'est un peu plus compliqué, j'ai utilisé le tutoriel basé ici :
    https://blog.jeroenhd.nl/article/android-7-nougat-and-certificate-authorities

    Sur une rom revolution os rooté, les lignes de commandes ne marchent pas, mais avec une application root browser j'ai réussi à le faire en copiant/collant et éditant les propriétés.

    J'ai commencé par télécharger le fichier https://letsencrypt.org/certs/isrgrootx1.pem pour le certificat ISRG Root X1 disponible sur https://letsencrypt.org/certificates/

    Ensuite j'ai copié/collé ce fichier sous /system/etc/security/cacerts/6187b673.0 vérifié que le fichier est en 0644 et root:root.

    J'ai ensuite viré le certificat expiré IdenTrust DST Root CA X3 présent dans /system/etc/security/cacerts/12d55845.0

    Ensuite ça ne marche pas directement, il faut redémarrer le téléphone, lol…

    Je n'ai pas compris ni réussi à faire les opérations en root dans un émulateur de terminal.

    J'ai maintenant un téléphone qui truste ISRG Root X1 par défaut.

    J'avais essayé d'installer le certificat en téléchargeant le fichier pem, puis en l'ouvrant, ça ne fonctionne pas.

    Andoid semble prendre uniquement en compte l'installation de certificat client pour VPN, Wifi ou application…

    Je souhaite bien du courage à ceux qui ne peuvent pas mettre à jour leur téléphone ou devenir administrateur dessus, c'est effrayant cette obsolescence programmée qui te bannis de tous les services sécurisés par letsencrypt…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.