• Ha chevron_right

      StartCom contre attaque

      raspbeguy · pubsub.gugod.fr / hashtagueule · Tuesday, 14 June, 2016 - 22:00 · 3 minutes

    Depuis l'ouverture de l'autorité de certification Let's Encrypt en décembre dernier, que de joie et d'allégresse ont été répandues en célébration de cette facilité nouvelle pour créer ses certificats. Tous les sysadmins amateurs, y compris nous, ont migré vers ce service qui permettait, une fois con...

    Depuis l'ouverture de l'autorité de certification Let's Encrypt en décembre dernier, que de joie et d'allégresse ont été répandues en célébration de cette facilité nouvelle pour créer ses certificats. Tous les sysadmins amateurs, y compris nous, ont migré vers ce service qui permettait, une fois configuré, de ne plus se soucier d'une corvée que la validation de certificats impose d'habitude.

    Par le fait, Let's Encrypt a gagné énormément d'utilisateurs en très peu de temps, au dépends d'autres autorités de certification, dont StartCom et son service StartSSL, qui fournit également des certificats gratuits reconnus par la plupart des navigateurs. Aujourd'hui, StartCom riposte avec un nouveau service automatisé.

    StartCom a envoyé un mail à ses utilisateurs pour annoncer la nouvelle.

    StartCom, a leading global Certificate Authority (CA) and provider of trusted identity and authentication services, announces a new service – StartEncrypt today, an automatic SSL certificate issuance and installation software for your web server.

    StartEncrypt is based the StartAPI system to let you get SSL certificate and install the SSL certificate in your web server for free and automatically, no any coding, just one click to install it in your server.

    Compare with Let’s Encrypt, StartEncrypt support Windows and Linux server for most popular web server software, and have many incomparable advantages as:

    (1) Not just get the SSL certificate automatically, but install it automatically;

    (2) Not just Encrypted, but also identity validated to display EV Green Bar and OV organization name in the certificate;

    (3) Not just 90 days period certificate, but up to 39 months, more than 1180 days;

    (4) Not just low assurance DV SSL certificate, but also high assurance OV SSL certificate and green bar EV SSL certificate;

    (5) Not just for one domain, but up to 120 domains with wildcard support;

    (6) All OV SSL certificate and EV SSL certificate are free, just make sure your StartSSL account is verified as Class 3 or Class 4 identity.

    StartEncrypt together with StartSSL to let your website start to https without any pain, to let your website keep green bar that give more confident to your online customer and bring to online revenue to you. Let’s start to encrypt now.

    Pour résumer, StartEncrypt supporte également les certificats plus "professionnels" (comprendre plus onéreux) dont les certificats EV, qui permettent d'avoir un témoin dans le navigateur indiquant la société qui possède le certificat (cette catégorie de certificats indique que la vérification d'identité est plus stricte, mais sur le plan algorithmique, la sécurité est la même), ainsi que les wildcard (nombre de sous-domaines illimités).

    Du point de vue technique, l'utilitaire fourni par StartCom est un binaire opaque, en licence propriétaire, et il est donc impossible de vérifier les effet du programme, d'autant plus qu'il s'exécute en root et que l'une des fonctionnalités est de toucher directement aux configurations du serveur web, comme ce que propose Let's Encrypt, et donc les chances de casser une installation existent (que ce soit à cause de cochonneries volontaires ou de bugs d'innatention ce qui arrive plus souvent que ce que l'on veut bien croire).

    Précisons que si on tient à rester sous StartSSL, il existe une API qui permettait d'automatiser ce travail bien avant StartEncrypt, et dont des implémentations par des tiers sont trouvables, même si je n'en ai pour le moment testé aucune.

    • At chevron_right

      StartCom contre attaque

      raspbeguy · pubsub.gugod.fr / atomtest · Tuesday, 14 June, 2016 - 22:00 · 3 minutes

    Depuis l'ouverture de l'autorité de certification Let's Encrypt en décembre dernier, que de joie et d'allégresse ont été répandues en célébration de cette facilité nouvelle pour créer ses certificats. Tous les sysadmins amateurs, y compris nous, ont migré vers ce service qui permettait, une fois con...

    Depuis l'ouverture de l'autorité de certification Let's Encrypt en décembre dernier, que de joie et d'allégresse ont été répandues en célébration de cette facilité nouvelle pour créer ses certificats. Tous les sysadmins amateurs, y compris nous, ont migré vers ce service qui permettait, une fois configuré, de ne plus se soucier d'une corvée que la validation de certificats impose d'habitude.

    Par le fait, Let's Encrypt a gagné énormément d'utilisateurs en très peu de temps, au dépends d'autres autorités de certification, dont StartCom et son service StartSSL, qui fournit également des certificats gratuits reconnus par la plupart des navigateurs. Aujourd'hui, StartCom riposte avec un nouveau service automatisé.

    StartCom a envoyé un mail à ses utilisateurs pour annoncer la nouvelle.

    StartCom, a leading global Certificate Authority (CA) and provider of trusted identity and authentication services, announces a new service – StartEncrypt today, an automatic SSL certificate issuance and installation software for your web server.

    StartEncrypt is based the StartAPI system to let you get SSL certificate and install the SSL certificate in your web server for free and automatically, no any coding, just one click to install it in your server.

    Compare with Let’s Encrypt, StartEncrypt support Windows and Linux server for most popular web server software, and have many incomparable advantages as:

    (1) Not just get the SSL certificate automatically, but install it automatically;

    (2) Not just Encrypted, but also identity validated to display EV Green Bar and OV organization name in the certificate;

    (3) Not just 90 days period certificate, but up to 39 months, more than 1180 days;

    (4) Not just low assurance DV SSL certificate, but also high assurance OV SSL certificate and green bar EV SSL certificate;

    (5) Not just for one domain, but up to 120 domains with wildcard support;

    (6) All OV SSL certificate and EV SSL certificate are free, just make sure your StartSSL account is verified as Class 3 or Class 4 identity.

    StartEncrypt together with StartSSL to let your website start to https without any pain, to let your website keep green bar that give more confident to your online customer and bring to online revenue to you. Let’s start to encrypt now.

    Pour résumer, StartEncrypt supporte également les certificats plus "professionnels" (comprendre plus onéreux) dont les certificats EV, qui permettent d'avoir un témoin dans le navigateur indiquant la société qui possède le certificat (cette catégorie de certificats indique que la vérification d'identité est plus stricte, mais sur le plan algorithmique, la sécurité est la même), ainsi que les wildcard (nombre de sous-domaines illimités).

    Du point de vue technique, l'utilitaire fourni par StartCom est un binaire opaque, en licence propriétaire, et il est donc impossible de vérifier les effet du programme, d'autant plus qu'il s'exécute en root et que l'une des fonctionnalités est de toucher directement aux configurations du serveur web, comme ce que propose Let's Encrypt, et donc les chances de casser une installation existent (que ce soit à cause de cochonneries volontaires ou de bugs d'innatention ce qui arrive plus souvent que ce que l'on veut bien croire).

    Précisons que si on tient à rester sous StartSSL, il existe une API qui permettait d'automatiser ce travail bien avant StartEncrypt, et dont des implémentations par des tiers sont trouvables, même si je n'en ai pour le moment testé aucune.

    • Ha chevron_right

      Sécuriser ses sites web avec Let's Encrypt

      raspbeguy · pubsub.gugod.fr / hashtagueule · Friday, 1 January, 2016 - 23:00 · 10 minutes

    Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en t...

    Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en toute simplicité et sans avoir besoin de faire perdre une après-midi à son petit neveux du côté de sa belle-mère, qui se trouve être administrateur système, afin qu'il lui répète une quinzaine de fois les étapes de création et de validation d'un certificat en bonne et due forme. Ah, la famille...

    Mais tout d’abord, je vous souhaite à tous une bonne année 211 - 25 ! Au niveau personnel, je vous souhaite tout le bonheur que vous méritez, tant sur le plan professionnel/scolaire qu'avec votre famille/amis/béguin divers. Instruisez-vous, soyez curieux, incitez vos proches à la sagesse, et bien sûr, restez vous-même gentils.

    Au niveau citoyen, je souhaite comme toujours une prise de conscience collective sur cette cage en or qu'est devenue aujourd'hui la vie sur les internets, et une plus grande sagesse de nos têtes décideuses (à défaut d'être pensantes) à propos de la réalité numérique, qu'elles n'ont toujours pas bien intégrée.


    Enfin, revenons à notre tutoriel. Au cours du mois dernier, vous l'avez peut-être remarqué, le certificat de notre blog (ainsi que les certificats de nos services internes, mais ça c'est nos oignons) ont changé d'autorité de certification. Nous sommes passés d'un certificat Gandi, offert avec notre nom de domaine, à un certificat Let's Encrypt, grâce à l'ouverture de ce service en bêta publique. Pourquoi avons-nous changé ? Et bien, d'abord, depuis le temps que nous vous en parlions, il aurait été ironique que nous n'utilisions pas le système Let's Encrypt. Ensuite, cette manière de procéder n'est pas sans avantages pour un administrateur système, principalement pour les raisons suivantes :

    • Gain de temps global, même pour la première utilisation ;
    • Possibilité de créer un seul certificat pour plusieurs domaines ;
    • Automatisation très poussée des différentes étapes, permettant l'écriture de scripts pour les renouvèlements.

    J'avoue qu'avant la bêta publique et la possibilité de mettre vraiment les mains dans le cambouis, je n'avais aucune idée du fonctionnement, même basique, de ce service. Je n'ai même jamais personnellement manifesté d'attirance particulière envers les technologies de sécurité. En fait, son fonctionnement théorique est très simple, et permet même, à mon sens, de se rendre bien compte du processus de certification SSL dans sa globalité.

    Principe de la vérification d'identité

    Lors de la création d'un certificat, on doit suivre un protocole invariant de l'autorité de certification :

    1. On crée une clef secrète (ou on utilise une clef générée antérieurement).
    2. À partir de cette clef secrète, on génère une demande de certification (contenant une clef publique et des informations sur l'identité de l'entité à certifier).
    3. On soumet cette demande à l'autorité de certification désirée, qui génère et signe un certificat, ce qui dit aux outils des utilisateurs de votre service qu'il s'agit bien de vous, car il fait confiance à l'autorité de certification.

    Les deux premières étapes sont instantanées ; cependant, la dernière étape prends traditionnellement plus de temps, car l'autorité de certification doit s'assurer de l'identité du domaine qu'elle doit certifier. Chez les autorités classiques, il s'agit souvent de fournir des pièces d'identités, ou de répondre à un mail auquel seul le possesseur du domaine peut accéder (du type admin@example.com).

    Let's Encrypt prends en charge ces 3 étapes (il faut reconnaitre que c'est très facile d'automatiser les 2 premières) en passant par un utilitaire chargé de communiquer avec le serveur de son autorité de certification.

    Schéma

    Processus de vérification d'identité

    1. Une fois la clef et la demande de certificat générées, l'exécutable local communique au serveur http un code de vérification à rendre accessible par le serveur de certification.
    2. L'utilitaire demande à l'autorité de certification de procéder à une vérification d'identité en envoyant la demande de certificat et lui communique le code servi par le serveur http à tester.
    3. Le serveur de certification accède au serveur http en utilisant le système DNS
    4. L'autorité de certification accepte l'identité et transfert le certificat.
    5. L'utilitaire met le certificat généré à disposition des services de l’utilisateur.

    Ainsi, le processus de création du certificat ne prends en tout et pour tout que quelques dizaines de secondes. Cependant, par cette méthode, on est contraint de mettre en service, au moins temporairement, un service web pour chaque domaine à tester, ce qui est gênant pour des domaines qui ne sont pas destinés à pointer sur un site web.

    Configurer son serveur web

    Let's Encrypt met à disposition des "extensions" lui permettant de communiquer tout seul au serveur web les informations pour l'étape de la vérification d'identité. Cependant, j'utilise Nginx, et à ce jour seul Apache dispose d'une extension stable. Il existe une extension expérimentale pour Nginx mais je n'ai pas su m'en servir convenablement, ou alors j'ai eu la flemme de comprendre comment elle marchait. De toute façon, selon les retours utilisateurs et les forums, la méthode générique (dite du webroot) est la plus utilisée, c'est donc celle qui sera présentée, et vous verrez, ce ne sera pas bien compliqué.

    Tout d'abord, il faut définir le dossier qui sera mis à disposition par le serveur web. Par exemple, pour pouvez créer et choisir l'emplacement /var/www/webrootauth.

    Vous devez ensuite modifier la configuration de chaque domaine que vous souhaitez faire certifier. Vous avez le droit à 100 domaines couverts par votre certificat, vous avez donc de la marge, et vous auriez tort de vous priver. Sous Nginx, vous devez ajouter au sein de chaque server block :

    location ~ ^/.well-known/acme-challenge(/.*)?$ {
        root /var/www/webrootauth;
        default_type text/plain;
    }

    Sans oublier de recharger Nginx :

    service nginx restart

    ou bien, selon votre distribution Linux :

    systemctl restart nginx

    Pour information, cela demande à Nginx de servir le contenu de /var/www/webrootauth à l'adresse http://example.com/.well-known/acme-challenge/, adresse qui sela utilisée par l'autorité de certification.

    Installer l'utilitaire

    EDIT : C'était prévisible, maintenant quelques distributions intègrent Let's Encrypt dans leurs dépôts. Cette méthode est donc à privilégier par rapport à la méthode ci dessous.

    Il faut maintenant télécharger l'exécutable mis à disposition par Let's Encrypt. Pour cela, vous allez avoir besoin de Git, veillez donc à ce qu'il soit installé sur votre machine.

    Devenez super-utilisateur :

    sudo su -

    Puis clonez le dépôt du projet :

    git clone https://github.com/letsencrypt/letsencrypt /root/letsencrypt

    Configurer Let's Encrypt

    Il est possible d'exécuter Let's Encrypt à la sauvage sans fichier de configuration, uniquement avec des paramètres long comme mon bras. Il est néanmoins plus propre d'écrire son fichier de configuration, cela donne des scripts plus propres et un historique bash plus clair. Et comme ça vous n'avez pas des tonnes de lignes de commandes à retenir en cas de perte de vos scripts :)

    Un fichier de configuration Lets Encrypt ressemble à ceci :

    rsa-key-size = 4096
    server = https://acme-v01.api.letsencrypt.org/directory
    email = votreadresse@domaine.truc
    authenticator = webroot
    webroot-path = /var/www/webrootauth
    text = True
    renew-by-default = True
    agree-tos = True
    domains = hashtagueule.fr,mail.hashtagueule.fr,wiki.hashtagueule.fr,mysql.hashtagueule.fr,znc.hashtagueule.fr,ttrss.hashtagueule.fr

    Petite explication :

    • rsa-key-size : la taille de la clef, on l'a mis au maximum, parce qu'on est des gros bourrins. Sachez que la génération d'une clef 4096 bits prends plus de temps, mais elle n'est générée qu'à la première exécution.
    • server : l'adresse du serveur de certification. Ça ne sert à rien de le changer.
    • email : l'adresse e-mail de votre compte Let's Encrypt (s'il n'existe pas, il sera créé automatiquement, pas d’inquiétude).
    • authenticator : la méthode de vérification d'identité, on a dit qu'on choisissait la méthode webroot.
    • webroot-path : doit correspondre au chemin choisi précédemment.
    • text : indique que l'on souhaite exécuter l'outil en lignes de commandes, pratique pour les scripts et permet de tout exécuter sans intéraction (un mode pseudo-graphique existe mais n'est pas pratique).
    • renew-by-default : indique que les certificats existants doivent être renouvelés.
    • agree-tos : indique que vous acceptez la paperasse lié à l'utilisation des certificats, à lire quelque part sur leur site, mais bon, rien de bien méchant.
    • domains : là, vous devez indiquer tous les domaines que doit couvrir le certificat qui va être généré, séparés par une virgule.

    Vous placerez ce fichier quelque part d'accessible. Par exemple, vous pouvez le placer dans /root/le-config/cli.ini.

    Générer ponctuellement le certificat

    Tout est en place pour la génération de votre premier certificat, la tension monte, je vous sens tout excité. Allez, lancez-vous, en voiture Simone. Pour générer votre certificat, en tant que super-utilisateur, exécutez la commande suivante :

    /root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini

    Laissez mijoter quelques instants. La première fois, des dépendances nécessaires vont s'installer, il va configurer deux trois trucs, et finalement faire le boulot.

    Normalement, à la fin, vous allez avoir un message vous félicitant du succès de l'opération. Bravo, vous avez un certificat Let's Encrypt :)

    Vous pourrez ensuite configurer votre serveur web pour utiliser ce certificat. Sous Nginx, vous préciserez dans vos server blocks :

    listen 443;
    listen [::]:443;
    ssl on;
    ssl_certificate /etc/letsencrypt/live/hashtagueule.fr/fullchain.pem;
    ssl_certificate\_key /etc/letsencrypt/live/hashtagueule.fr/privkey.pem;

    Bien sûr, vous remplacerez hashtagueule.fr par le nom de votre domaine principal. Vérifiez en regardant le nom du dossier à cet emplacement.

    Vous pouvez ensuite recharger Nginx, et si tout ce passe bien, vous avez un site sécurisé Let's Encrypt.

    Renouvellement automatique

    Les certificats générés par Let's Encrypt ont une validité de 90 jours. C'est court, et c'est un fil à la patte de devoir tous les 3 mois demander un renouvellement de certificat. Heureusement, il y a Cron.

    Cron est un service sur votre machine qui va se charger d'exécuter des tâches à intervalle régulier. Tous ce que vous avez à faire, c'est d'écrire un script à fournir à cron. Ce script ressemblera à ça :

    #!/bin/bash
    
    la_cert_dir=/etc/letsencrypt/live/hashtagueule.fr
    
    /root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini 1> /dev/null
    
    # nginx
    service nginx reload
    
    # Vous pouvez également scripter les opération à suivre
    # pour d'autres services, par exemple votre serveur mail.
    
    # Envoi d'un mail de notification à l'administrateur
    mail -a "From: Agent de certification Hashtagueule <letsencrypt@hashtagueule.fr>" -a "Content-Type: text/plain; charset=UTF-8" -s "Renouvellement des certificats" votreadresse@domaine.truc << EOF
    Bonjour,
    
    Le certificat des services Hashtagueule a été renouvelé et couvre actuellement les domaines suivants :
    
    $(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -noout -text | grep DNS | sed 's/, /\n/g' | cut -d: -f2)
    
    Dates de validité :
    
    $(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -dates -noout | cut -d= -f2)
    
    Pour rappel, les certificats délivrés par Let's Encrypt ont toujours une validité de 3 mois. Tâchez donc de définir une période de renouvellement inférieure à cette durée.
    Il est à noter également que l'autorité Let's Encrypt ne délivre qu'un maximum de 5 certificats pour le même domaine par semaine. Renouvelez donc avec précaution.
    
    Bonne journée.
    EOF

    Ce script va renouveler le certificat et vous envoyer un mail de notification comportant les nouvelles dates de validité et les domaines concernés. Classe, non ?

    Il vous reste à rendre ce script exécutable et à le placer dans /etc/cron.monthly afin de l'exécuter tous les mois.

    Limitations

    Comme indiqué précédemment, les domaines à certifier doivent être servis par un serveur web, au moins pour la durée de la vérification d'identité.

    D'autre part, évitez de générer trop de certificats, car vous êtes limités à 5 renouvèlements par semaine. En régime permanent ça ne pose pas de problème, mais je me suis déjà fait avoir lors de mes tests...

    Voilà, j'espère que ce tutoriel vous aura été utile, et j'espère aussi voir fleurir une multitude de sites sécurisés.

    Désormais, vous n'avez plus aucune excuse.

    • At chevron_right

      Sécuriser ses sites web avec Let's Encrypt

      raspbeguy · pubsub.gugod.fr / atomtest · Friday, 1 January, 2016 - 23:00 · 10 minutes

    Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en t...

    Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en toute simplicité et sans avoir besoin de faire perdre une après-midi à son petit neveux du côté de sa belle-mère, qui se trouve être administrateur système, afin qu'il lui répète une quinzaine de fois les étapes de création et de validation d'un certificat en bonne et due forme. Ah, la famille...

    Mais tout d’abord, je vous souhaite à tous une bonne année 211 - 25 ! Au niveau personnel, je vous souhaite tout le bonheur que vous méritez, tant sur le plan professionnel/scolaire qu'avec votre famille/amis/béguin divers. Instruisez-vous, soyez curieux, incitez vos proches à la sagesse, et bien sûr, restez vous-même gentils.

    Au niveau citoyen, je souhaite comme toujours une prise de conscience collective sur cette cage en or qu'est devenue aujourd'hui la vie sur les internets, et une plus grande sagesse de nos têtes décideuses (à défaut d'être pensantes) à propos de la réalité numérique, qu'elles n'ont toujours pas bien intégrée.


    Enfin, revenons à notre tutoriel. Au cours du mois dernier, vous l'avez peut-être remarqué, le certificat de notre blog (ainsi que les certificats de nos services internes, mais ça c'est nos oignons) ont changé d'autorité de certification. Nous sommes passés d'un certificat Gandi, offert avec notre nom de domaine, à un certificat Let's Encrypt, grâce à l'ouverture de ce service en bêta publique. Pourquoi avons-nous changé ? Et bien, d'abord, depuis le temps que nous vous en parlions, il aurait été ironique que nous n'utilisions pas le système Let's Encrypt. Ensuite, cette manière de procéder n'est pas sans avantages pour un administrateur système, principalement pour les raisons suivantes :

    • Gain de temps global, même pour la première utilisation ;
    • Possibilité de créer un seul certificat pour plusieurs domaines ;
    • Automatisation très poussée des différentes étapes, permettant l'écriture de scripts pour les renouvèlements.

    J'avoue qu'avant la bêta publique et la possibilité de mettre vraiment les mains dans le cambouis, je n'avais aucune idée du fonctionnement, même basique, de ce service. Je n'ai même jamais personnellement manifesté d'attirance particulière envers les technologies de sécurité. En fait, son fonctionnement théorique est très simple, et permet même, à mon sens, de se rendre bien compte du processus de certification SSL dans sa globalité.

    Principe de la vérification d'identité

    Lors de la création d'un certificat, on doit suivre un protocole invariant de l'autorité de certification :

    1. On crée une clef secrète (ou on utilise une clef générée antérieurement).
    2. À partir de cette clef secrète, on génère une demande de certification (contenant une clef publique et des informations sur l'identité de l'entité à certifier).
    3. On soumet cette demande à l'autorité de certification désirée, qui génère et signe un certificat, ce qui dit aux outils des utilisateurs de votre service qu'il s'agit bien de vous, car il fait confiance à l'autorité de certification.

    Les deux premières étapes sont instantanées ; cependant, la dernière étape prends traditionnellement plus de temps, car l'autorité de certification doit s'assurer de l'identité du domaine qu'elle doit certifier. Chez les autorités classiques, il s'agit souvent de fournir des pièces d'identités, ou de répondre à un mail auquel seul le possesseur du domaine peut accéder (du type admin@example.com).

    Let's Encrypt prends en charge ces 3 étapes (il faut reconnaitre que c'est très facile d'automatiser les 2 premières) en passant par un utilitaire chargé de communiquer avec le serveur de son autorité de certification.

    Schéma

    Processus de vérification d'identité

    1. Une fois la clef et la demande de certificat générées, l'exécutable local communique au serveur http un code de vérification à rendre accessible par le serveur de certification.
    2. L'utilitaire demande à l'autorité de certification de procéder à une vérification d'identité en envoyant la demande de certificat et lui communique le code servi par le serveur http à tester.
    3. Le serveur de certification accède au serveur http en utilisant le système DNS
    4. L'autorité de certification accepte l'identité et transfert le certificat.
    5. L'utilitaire met le certificat généré à disposition des services de l’utilisateur.

    Ainsi, le processus de création du certificat ne prends en tout et pour tout que quelques dizaines de secondes. Cependant, par cette méthode, on est contraint de mettre en service, au moins temporairement, un service web pour chaque domaine à tester, ce qui est gênant pour des domaines qui ne sont pas destinés à pointer sur un site web.

    Configurer son serveur web

    Let's Encrypt met à disposition des "extensions" lui permettant de communiquer tout seul au serveur web les informations pour l'étape de la vérification d'identité. Cependant, j'utilise Nginx, et à ce jour seul Apache dispose d'une extension stable. Il existe une extension expérimentale pour Nginx mais je n'ai pas su m'en servir convenablement, ou alors j'ai eu la flemme de comprendre comment elle marchait. De toute façon, selon les retours utilisateurs et les forums, la méthode générique (dite du webroot) est la plus utilisée, c'est donc celle qui sera présentée, et vous verrez, ce ne sera pas bien compliqué.

    Tout d'abord, il faut définir le dossier qui sera mis à disposition par le serveur web. Par exemple, pour pouvez créer et choisir l'emplacement /var/www/webrootauth.

    Vous devez ensuite modifier la configuration de chaque domaine que vous souhaitez faire certifier. Vous avez le droit à 100 domaines couverts par votre certificat, vous avez donc de la marge, et vous auriez tort de vous priver. Sous Nginx, vous devez ajouter au sein de chaque server block :

    location ~ ^/.well-known/acme-challenge(/.*)?$ {
        root /var/www/webrootauth;
        default_type text/plain;
    }

    Sans oublier de recharger Nginx :

    service nginx restart

    ou bien, selon votre distribution Linux :

    systemctl restart nginx

    Pour information, cela demande à Nginx de servir le contenu de /var/www/webrootauth à l'adresse http://example.com/.well-known/acme-challenge/, adresse qui sela utilisée par l'autorité de certification.

    Installer l'utilitaire

    EDIT : C'était prévisible, maintenant quelques distributions intègrent Let's Encrypt dans leurs dépôts. Cette méthode est donc à privilégier par rapport à la méthode ci dessous.

    Il faut maintenant télécharger l'exécutable mis à disposition par Let's Encrypt. Pour cela, vous allez avoir besoin de Git, veillez donc à ce qu'il soit installé sur votre machine.

    Devenez super-utilisateur :

    sudo su -

    Puis clonez le dépôt du projet :

    git clone https://github.com/letsencrypt/letsencrypt /root/letsencrypt

    Configurer Let's Encrypt

    Il est possible d'exécuter Let's Encrypt à la sauvage sans fichier de configuration, uniquement avec des paramètres long comme mon bras. Il est néanmoins plus propre d'écrire son fichier de configuration, cela donne des scripts plus propres et un historique bash plus clair. Et comme ça vous n'avez pas des tonnes de lignes de commandes à retenir en cas de perte de vos scripts :)

    Un fichier de configuration Lets Encrypt ressemble à ceci :

    rsa-key-size = 4096
    server = https://acme-v01.api.letsencrypt.org/directory
    email = votreadresse@domaine.truc
    authenticator = webroot
    webroot-path = /var/www/webrootauth
    text = True
    renew-by-default = True
    agree-tos = True
    domains = hashtagueule.fr,mail.hashtagueule.fr,wiki.hashtagueule.fr,mysql.hashtagueule.fr,znc.hashtagueule.fr,ttrss.hashtagueule.fr

    Petite explication :

    • rsa-key-size : la taille de la clef, on l'a mis au maximum, parce qu'on est des gros bourrins. Sachez que la génération d'une clef 4096 bits prends plus de temps, mais elle n'est générée qu'à la première exécution.
    • server : l'adresse du serveur de certification. Ça ne sert à rien de le changer.
    • email : l'adresse e-mail de votre compte Let's Encrypt (s'il n'existe pas, il sera créé automatiquement, pas d’inquiétude).
    • authenticator : la méthode de vérification d'identité, on a dit qu'on choisissait la méthode webroot.
    • webroot-path : doit correspondre au chemin choisi précédemment.
    • text : indique que l'on souhaite exécuter l'outil en lignes de commandes, pratique pour les scripts et permet de tout exécuter sans intéraction (un mode pseudo-graphique existe mais n'est pas pratique).
    • renew-by-default : indique que les certificats existants doivent être renouvelés.
    • agree-tos : indique que vous acceptez la paperasse lié à l'utilisation des certificats, à lire quelque part sur leur site, mais bon, rien de bien méchant.
    • domains : là, vous devez indiquer tous les domaines que doit couvrir le certificat qui va être généré, séparés par une virgule.

    Vous placerez ce fichier quelque part d'accessible. Par exemple, vous pouvez le placer dans /root/le-config/cli.ini.

    Générer ponctuellement le certificat

    Tout est en place pour la génération de votre premier certificat, la tension monte, je vous sens tout excité. Allez, lancez-vous, en voiture Simone. Pour générer votre certificat, en tant que super-utilisateur, exécutez la commande suivante :

    /root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini

    Laissez mijoter quelques instants. La première fois, des dépendances nécessaires vont s'installer, il va configurer deux trois trucs, et finalement faire le boulot.

    Normalement, à la fin, vous allez avoir un message vous félicitant du succès de l'opération. Bravo, vous avez un certificat Let's Encrypt :)

    Vous pourrez ensuite configurer votre serveur web pour utiliser ce certificat. Sous Nginx, vous préciserez dans vos server blocks :

    listen 443;
    listen [::]:443;
    ssl on;
    ssl_certificate /etc/letsencrypt/live/hashtagueule.fr/fullchain.pem;
    ssl_certificate\_key /etc/letsencrypt/live/hashtagueule.fr/privkey.pem;

    Bien sûr, vous remplacerez hashtagueule.fr par le nom de votre domaine principal. Vérifiez en regardant le nom du dossier à cet emplacement.

    Vous pouvez ensuite recharger Nginx, et si tout ce passe bien, vous avez un site sécurisé Let's Encrypt.

    Renouvellement automatique

    Les certificats générés par Let's Encrypt ont une validité de 90 jours. C'est court, et c'est un fil à la patte de devoir tous les 3 mois demander un renouvellement de certificat. Heureusement, il y a Cron.

    Cron est un service sur votre machine qui va se charger d'exécuter des tâches à intervalle régulier. Tous ce que vous avez à faire, c'est d'écrire un script à fournir à cron. Ce script ressemblera à ça :

    #!/bin/bash
    
    la_cert_dir=/etc/letsencrypt/live/hashtagueule.fr
    
    /root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini 1> /dev/null
    
    # nginx
    service nginx reload
    
    # Vous pouvez également scripter les opération à suivre
    # pour d'autres services, par exemple votre serveur mail.
    
    # Envoi d'un mail de notification à l'administrateur
    mail -a "From: Agent de certification Hashtagueule <letsencrypt@hashtagueule.fr>" -a "Content-Type: text/plain; charset=UTF-8" -s "Renouvellement des certificats" votreadresse@domaine.truc << EOF
    Bonjour,
    
    Le certificat des services Hashtagueule a été renouvelé et couvre actuellement les domaines suivants :
    
    $(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -noout -text | grep DNS | sed 's/, /\n/g' | cut -d: -f2)
    
    Dates de validité :
    
    $(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -dates -noout | cut -d= -f2)
    
    Pour rappel, les certificats délivrés par Let's Encrypt ont toujours une validité de 3 mois. Tâchez donc de définir une période de renouvellement inférieure à cette durée.
    Il est à noter également que l'autorité Let's Encrypt ne délivre qu'un maximum de 5 certificats pour le même domaine par semaine. Renouvelez donc avec précaution.
    
    Bonne journée.
    EOF

    Ce script va renouveler le certificat et vous envoyer un mail de notification comportant les nouvelles dates de validité et les domaines concernés. Classe, non ?

    Il vous reste à rendre ce script exécutable et à le placer dans /etc/cron.monthly afin de l'exécuter tous les mois.

    Limitations

    Comme indiqué précédemment, les domaines à certifier doivent être servis par un serveur web, au moins pour la durée de la vérification d'identité.

    D'autre part, évitez de générer trop de certificats, car vous êtes limités à 5 renouvèlements par semaine. En régime permanent ça ne pose pas de problème, mais je me suis déjà fait avoir lors de mes tests...

    Voilà, j'espère que ce tutoriel vous aura été utile, et j'espère aussi voir fleurir une multitude de sites sécurisés.

    Désormais, vous n'avez plus aucune excuse.

    • At chevron_right

      Let's Encrypt

      motius · pubsub.gugod.fr / atomtest · Friday, 23 October, 2015 - 22:00 · 7 minutes

    Bonjour à tous ! Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt. Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement poi...

    Bonjour à tous !

    Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt.

    Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement point-à-point. On n'a pas encore fait de glossaire, donc je vais le réexpliquer à cette occasion, mais on finira par se référer à un petit manuel de bases. Donc si vous connaissez, vous pouvez zaper la partie 0 qui suit.

    Chiffrement de bout en bout vs chiffrement point à point.

    C'est assez simple :

    • le chiffrement de bout en bout signifie que votre ordinateur chiffre avec la clef de votre correspondant, et par conséquent sur le réseau, le message est toujours chiffré ;
    • le chiffrement point à point est appliqué entre vous et votre pair direct, puis (éventuellement) votre pair chiffre avec son pair, etc. jusqu'à destination, le message peut donc :
      • traverser un bout du réseau sans chiffrement ;
      • être lu par tous les pairs qui ont acheminé le message.
      • En comparaison, c'est comme si une lettre à La Poste était lu par tous ceux qui l'ont en main, et que de temps en temps le service de poste était négligent, et laissait à tous la possibilité de lire la lettre.

    Sur internet vous utilisez les deux :

    • le mail utilise le chiffrment point à point (sur lequel vous pouvez rajouter du chiffrement de bout en bout avec GPG/PGP) ;
    • parler HTTPS avec un serveur permet de récupérer une page qui sera chiffrée entre vous et le serveur, donc d'un bout du réseau à l'autre.

    Comment fonctionne le HTTPS ?

    HTTP vs HTTPS, méthode de chiffement

    HTTP est un protocole qui permet de récupérer des pages web. Exemples de ce qu'on peut "dire en HTTP" :

    • quand on est le client :
      • donne moi la page à cette URL ;
    • quand on est le serveur :
      • la page que tu m'as demandé, je l'ai, la voici ;
      • la page que tu m'as demandé, je l'ai, mais attends un peu, je suis surbooké, là (schématiquement) ;
      • la page que tu m'as demandé, bah elle existe pas (404) ;
      • ce que tu demandes n'est pas ici, va voir ailleurs (301) ;
      • j'ai pas compris ce que tu m'as demandé (400) ;
      • ce que tu fais-là, tu n'en as pas le droit (403) ;
      • le serveur est en panne (503)...

    Et beaucoup d'autres. HTTPS n'est que l'utilisation d'une couche de chiffrement (SSL/TLS) pour chiffrer les données :

    • la requête (pas celles initiant le chiffrement) ;
    • les données échangées par la suite.

    Pour visualiser la couche de chiffrement, on peut se représenter un tunnel entre le client et le serveur dans lequel la donnée passe. Personne ne peut accéder à l'intérieur du tunnel parce qu'il est solide, et le tunnel a une entrée (le client) et une sortie (le serveur).

    Confiance de HTTPS

    Lorsqu'Alice va demander la page web de Bob en HTTPS, que va-t-il se passer ?

    • Le client A (son navigateur web Firefox) va faire une requête vers un serveur B
    • B qui va indiquer qu'il sait parler HTTPS ;
    • A va interroger B ;
    • B va répondre, et s'il a la page, la transmettre.

    Tout ça s'est fait automatiquement. Voyons un peu l'architecture de chiffrement mise en place ici. Il s'agit d'une infrastructure clef publique/clef privée + autorité de confiance :

    • A va obtenir via le réseau la clef publique de B.
    • Le navigateur web de A va vérifier que la clef est valide, c'est à dire qu'il s'agit bien de la bonne clef (et pas celle d'un attaquant) et qu'elle est toujours valide (par mesure de sécurité, les clefs ont une durée de validité, d'un an en général).
    • A va chiffrer ses messages pour B avec la clef publique de B.
    • B déchiffre ses messages avec sa clef privée.

    Ainsi, la confiance que l'on a dans HTTPS dépend de deux facteurs :

    • comment le navigateur reconnait qu'un certificat est valide ;
    • la qualité du chiffrement, ie les algorithmes utilisés (RC4 : mauvais, AES-256 très bon, à ce jour).

    On ne parlera pas plus des algorithmes ici, à la place on se concentrera sur comment le navigateur a décidé de reconnaître un certificat, ou de l'invalider.

    Réseau de confiance de l'architecture X509

    Le problème de fond, c'est de reconnaître la validité d'une clef de chiffrement (publique) pouvant changer fréquemment obtenue via internet.

    On utilise ce qu'on appelle un pair de confiance. Si un certificat est signé par un pair de confiance, alors le certificat est considéré comme valide. Le pair de confiance dans l'architecture X509 s'appelle une autorité de certification (AC, parce que j'ai pas envie de le réécrire ;) ). Par défaut Firefox fait donc confiance à un certaint nombre d'AC.

    Ainsi lorsqu'une clef publique arrive depuis internet :

    • si le certificat est signé par une AC, il est valide (sauf cas exceptionnel où l'utilisateur a interdit le certificat) ;
    • si le certificat n'est pas signé par une AC, mais est accepté par l'utilisateur, il est valide ;
    • le reste poubelle, la connexion est terminée.

    Dans les AC vous en connaissez peut-être quelques unes dont Thawte, VeriSign, GoDaddy, CA-Cert, Gandi, Google (eh oui, il font ça aussi), et depuis peu Let's Encrypt.

    Mais la chaîne de confiance n'est pas complète. Comment savoir quelles sont les entités reconnues, comment en rajouter sans mettre à jour tous les navigateurs ?

    Eh bien à la base de la création de X509, on a généré une clef c0, et une clef c1, on a signé la clef c1 avec la clef c0 et découpé c0 en plusieurs (4 ?) parties qu'on a dispachées dans des coffres-forts. On fait donc en sorte que la clef 0 soit reconnue, et on signe les AC avec la clef c1. Les entités créent leur clef c_entite (plusieurs en fait), qui est valide, puisque signée par c1, elle-même valide puisque signée par c0.

    Récapitulons. On fait confiance à c0. c0 signe c1, de telle sorte que :

    • c1 puisse signer des certificats ;
    • c1 puisse signer des AC ;

    On signe les AC, qui créent leur clefs, qui sont signées par c1 de telle sorte que :

    • elles puissent signer des certificats ;
    • éventuellement elles puissent signer d'autres AC.

    Ainsi, la chaîne de confiance est une hiérarchie. Faire confiance à c0 permet/implique a priori de faire confiance à beaucoup de gens (on peut cependant demander à Firefox de ne pas accepter un certificat valide).

    Subtilité de X509, résilience

    Vous avez peut-être remarqué que c0 ne sert qu'à signer c1, puis on demande au navigateur de reconnaître c0, puis on signe avec c1.

    Vous vous demandez peut être pourquoi... Imaginons que c0 = c1 = c$latex \alpha $, c'est à dire qu'au début de la chaîne de confiance il y ait non pas deux mais une seule clef c$latex \alpha $.

    Un problème se pose, et a pas mal de répercussions :

    Si la clef $latex \alpha $ est perdue alors toute la sécurité de l'architecture X509 s'effondre.

    • Dans le cas où on n'a qu'une clef c$latex \alpha $, on ne peut rien faire.
    • Dans le cas ou on a c0 et c1, et c1 est perdue (on suppose que c0 n'est pas perdue, elle sous clef, éparpillée sur le globe), on révoque c1 à l'aide de c0, et on regénère une clef c1'. Ça permet notamment de pouvoir rapidement recréer un environnement de confiance, et de ne pas avoir besoin de rediffuser la clef à toutes les machines.

    Let's Encrypt

    Alors pourquoi est-ce que je vous rabats les oreilles avec tout ça ? Eh bien pour deux raisons :

    • d'abord pour que vous sachiez quelle confiance accorder dans des connexions HTTPS ;
    • ensuite pour vous parler spécialement d'une AC : Let's Encrypt.

    Vous l'avez compris, il y a beaucoup d'enjeux concernant une AC. La confiance qu'on a, la qualité de son travail, de la façon dont elle sécurise ses données pour ne pas perdre sa clef et servir de vecteur d'attaque, etc. Il y a d'autres enjeux dont la possibilité pour tous de chiffrer facilement, en effet les certificats ne sont pas gratuits, sauf certains de CA-Cert, et de Gandi.

    C'est pourquoi Mozilla Cisco l'EFF et d'autres se sont unis pour créer une AC dont le but serit de permettre à tous de pratiquer le chiffrement à tour de bras. Et voilà qui est fait.

    Depuis le 19 octobre 2015 les certificats de Let's Encrypt sont de confiance par défaut dans les versions récentes de Firefox (probablement Chrome/Chromium, Microsoft Edge, et Safari).

    Let's Encrypt va donc pouvoir se mettre à un rythme de croisière de signatures de certificats d'ici très peu de temps.

    Bon chiffrement à tous et bonne journée !

    Motius

    • Ha chevron_right

      Let's Encrypt

      motius · pubsub.gugod.fr / hashtagueule · Friday, 23 October, 2015 - 22:00 · 7 minutes

    Bonjour à tous ! Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt. Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement poi...

    Bonjour à tous !

    Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt.

    Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement point-à-point. On n'a pas encore fait de glossaire, donc je vais le réexpliquer à cette occasion, mais on finira par se référer à un petit manuel de bases. Donc si vous connaissez, vous pouvez zaper la partie 0 qui suit.

    Chiffrement de bout en bout vs chiffrement point à point.

    C'est assez simple :

    • le chiffrement de bout en bout signifie que votre ordinateur chiffre avec la clef de votre correspondant, et par conséquent sur le réseau, le message est toujours chiffré ;
    • le chiffrement point à point est appliqué entre vous et votre pair direct, puis (éventuellement) votre pair chiffre avec son pair, etc. jusqu'à destination, le message peut donc :
      • traverser un bout du réseau sans chiffrement ;
      • être lu par tous les pairs qui ont acheminé le message.
      • En comparaison, c'est comme si une lettre à La Poste était lu par tous ceux qui l'ont en main, et que de temps en temps le service de poste était négligent, et laissait à tous la possibilité de lire la lettre.

    Sur internet vous utilisez les deux :

    • le mail utilise le chiffrment point à point (sur lequel vous pouvez rajouter du chiffrement de bout en bout avec GPG/PGP) ;
    • parler HTTPS avec un serveur permet de récupérer une page qui sera chiffrée entre vous et le serveur, donc d'un bout du réseau à l'autre.

    Comment fonctionne le HTTPS ?

    HTTP vs HTTPS, méthode de chiffement

    HTTP est un protocole qui permet de récupérer des pages web. Exemples de ce qu'on peut "dire en HTTP" :

    • quand on est le client :
      • donne moi la page à cette URL ;
    • quand on est le serveur :
      • la page que tu m'as demandé, je l'ai, la voici ;
      • la page que tu m'as demandé, je l'ai, mais attends un peu, je suis surbooké, là (schématiquement) ;
      • la page que tu m'as demandé, bah elle existe pas (404) ;
      • ce que tu demandes n'est pas ici, va voir ailleurs (301) ;
      • j'ai pas compris ce que tu m'as demandé (400) ;
      • ce que tu fais-là, tu n'en as pas le droit (403) ;
      • le serveur est en panne (503)...

    Et beaucoup d'autres. HTTPS n'est que l'utilisation d'une couche de chiffrement (SSL/TLS) pour chiffrer les données :

    • la requête (pas celles initiant le chiffrement) ;
    • les données échangées par la suite.

    Pour visualiser la couche de chiffrement, on peut se représenter un tunnel entre le client et le serveur dans lequel la donnée passe. Personne ne peut accéder à l'intérieur du tunnel parce qu'il est solide, et le tunnel a une entrée (le client) et une sortie (le serveur).

    Confiance de HTTPS

    Lorsqu'Alice va demander la page web de Bob en HTTPS, que va-t-il se passer ?

    • Le client A (son navigateur web Firefox) va faire une requête vers un serveur B
    • B qui va indiquer qu'il sait parler HTTPS ;
    • A va interroger B ;
    • B va répondre, et s'il a la page, la transmettre.

    Tout ça s'est fait automatiquement. Voyons un peu l'architecture de chiffrement mise en place ici. Il s'agit d'une infrastructure clef publique/clef privée + autorité de confiance :

    • A va obtenir via le réseau la clef publique de B.
    • Le navigateur web de A va vérifier que la clef est valide, c'est à dire qu'il s'agit bien de la bonne clef (et pas celle d'un attaquant) et qu'elle est toujours valide (par mesure de sécurité, les clefs ont une durée de validité, d'un an en général).
    • A va chiffrer ses messages pour B avec la clef publique de B.
    • B déchiffre ses messages avec sa clef privée.

    Ainsi, la confiance que l'on a dans HTTPS dépend de deux facteurs :

    • comment le navigateur reconnait qu'un certificat est valide ;
    • la qualité du chiffrement, ie les algorithmes utilisés (RC4 : mauvais, AES-256 très bon, à ce jour).

    On ne parlera pas plus des algorithmes ici, à la place on se concentrera sur comment le navigateur a décidé de reconnaître un certificat, ou de l'invalider.

    Réseau de confiance de l'architecture X509

    Le problème de fond, c'est de reconnaître la validité d'une clef de chiffrement (publique) pouvant changer fréquemment obtenue via internet.

    On utilise ce qu'on appelle un pair de confiance. Si un certificat est signé par un pair de confiance, alors le certificat est considéré comme valide. Le pair de confiance dans l'architecture X509 s'appelle une autorité de certification (AC, parce que j'ai pas envie de le réécrire ;) ). Par défaut Firefox fait donc confiance à un certaint nombre d'AC.

    Ainsi lorsqu'une clef publique arrive depuis internet :

    • si le certificat est signé par une AC, il est valide (sauf cas exceptionnel où l'utilisateur a interdit le certificat) ;
    • si le certificat n'est pas signé par une AC, mais est accepté par l'utilisateur, il est valide ;
    • le reste poubelle, la connexion est terminée.

    Dans les AC vous en connaissez peut-être quelques unes dont Thawte, VeriSign, GoDaddy, CA-Cert, Gandi, Google (eh oui, il font ça aussi), et depuis peu Let's Encrypt.

    Mais la chaîne de confiance n'est pas complète. Comment savoir quelles sont les entités reconnues, comment en rajouter sans mettre à jour tous les navigateurs ?

    Eh bien à la base de la création de X509, on a généré une clef c0, et une clef c1, on a signé la clef c1 avec la clef c0 et découpé c0 en plusieurs (4 ?) parties qu'on a dispachées dans des coffres-forts. On fait donc en sorte que la clef 0 soit reconnue, et on signe les AC avec la clef c1. Les entités créent leur clef c_entite (plusieurs en fait), qui est valide, puisque signée par c1, elle-même valide puisque signée par c0.

    Récapitulons. On fait confiance à c0. c0 signe c1, de telle sorte que :

    • c1 puisse signer des certificats ;
    • c1 puisse signer des AC ;

    On signe les AC, qui créent leur clefs, qui sont signées par c1 de telle sorte que :

    • elles puissent signer des certificats ;
    • éventuellement elles puissent signer d'autres AC.

    Ainsi, la chaîne de confiance est une hiérarchie. Faire confiance à c0 permet/implique a priori de faire confiance à beaucoup de gens (on peut cependant demander à Firefox de ne pas accepter un certificat valide).

    Subtilité de X509, résilience

    Vous avez peut-être remarqué que c0 ne sert qu'à signer c1, puis on demande au navigateur de reconnaître c0, puis on signe avec c1.

    Vous vous demandez peut être pourquoi... Imaginons que c0 = c1 = c$latex \alpha $, c'est à dire qu'au début de la chaîne de confiance il y ait non pas deux mais une seule clef c$latex \alpha $.

    Un problème se pose, et a pas mal de répercussions :

    Si la clef $latex \alpha $ est perdue alors toute la sécurité de l'architecture X509 s'effondre.

    • Dans le cas où on n'a qu'une clef c$latex \alpha $, on ne peut rien faire.
    • Dans le cas ou on a c0 et c1, et c1 est perdue (on suppose que c0 n'est pas perdue, elle sous clef, éparpillée sur le globe), on révoque c1 à l'aide de c0, et on regénère une clef c1'. Ça permet notamment de pouvoir rapidement recréer un environnement de confiance, et de ne pas avoir besoin de rediffuser la clef à toutes les machines.

    Let's Encrypt

    Alors pourquoi est-ce que je vous rabats les oreilles avec tout ça ? Eh bien pour deux raisons :

    • d'abord pour que vous sachiez quelle confiance accorder dans des connexions HTTPS ;
    • ensuite pour vous parler spécialement d'une AC : Let's Encrypt.

    Vous l'avez compris, il y a beaucoup d'enjeux concernant une AC. La confiance qu'on a, la qualité de son travail, de la façon dont elle sécurise ses données pour ne pas perdre sa clef et servir de vecteur d'attaque, etc. Il y a d'autres enjeux dont la possibilité pour tous de chiffrer facilement, en effet les certificats ne sont pas gratuits, sauf certains de CA-Cert, et de Gandi.

    C'est pourquoi Mozilla Cisco l'EFF et d'autres se sont unis pour créer une AC dont le but serit de permettre à tous de pratiquer le chiffrement à tour de bras. Et voilà qui est fait.

    Depuis le 19 octobre 2015 les certificats de Let's Encrypt sont de confiance par défaut dans les versions récentes de Firefox (probablement Chrome/Chromium, Microsoft Edge, et Safari).

    Let's Encrypt va donc pouvoir se mettre à un rythme de croisière de signatures de certificats d'ici très peu de temps.

    Bon chiffrement à tous et bonne journée !

    Motius