Note de service : HTTPS par Let’s Encrypt

Courant mars, j’annonçais le passage à Let’s Encrypt pour la gestion des certificats. Je donnais rendez-vous aux lecteurs aujourd’hui 26 mai pour la vérification du renouvellement automatique du certificat.

Il se trouve que le certificat a été renouvelé bien avant puisque la période de validité actuelle s’étend du 27 avril 2017 au 26 juillet 2017. J’en déduis donc que la « mise à jour » du certificat peut intervenir dans les 30 jours précédents son expiration.

Installation d’un package npm depuis un dépôt GitLab

Pour utiliser un dépôt hébergé sur sa propre instance GitLab, rien de bien compliquer, si ce n’est le protocole à utiliser : git+https et pas juste https (ou git+http au lieu de http).

Ce qui nous donne pour la branche master d’un projet :

{
  ...
  "dependencies": {
    "mon-projet": "git+https://<mon-domaine-gitlab>/<user>/<mon-projet>#master",
    ...
  }
}

Illustration pour récupérer une configuration eslint sous forme de module dans son dépôt propre :

{
  ...
  "devDependencies": {
    "eslint-config-unicoda": "git+https://gitlab.unicoda.com/vvision/javascript-convention#master",
    ...
  }
}

Let’s Encrypt. Enfin!

Cela fait pratiquement une éternité dans le monde de l’informatique que l’initiative Let’s Encrypt a été lancé. Je dois dire que si l’idée me plaisait beaucoup, au moment où les premières annonces avaient été faites, j’ai longtemps répugné à m’y mettre. Jusqu’à présent, j’utilisais StartSSL pour établir mes différents certificats. Avec quelques limitations bien sûr, un certificat par sous-domaine, génération d’une demande de certificat sur le serveur, transfert des infos vers StartSSL, récupération du certificat, transfert des fichiers sur le serveur et redémarrage d’Apache. De nombreuses opérations manuelles donc, mais une fois la procédure en place, c’est relativement rapide et les certificats ainsi générés sont valables un an. Pas de nécessité donc de mettre en place des certificats Let’s Encrypt, même si j’ai suivi les expérimentations des uns et des autres avec intérêt, et gardé en marque-page certains articles sur le sujet.

Tout allait bien dans le meilleur des mondes, jusqu’à la sortie de Firefox 51. En effet, à partir de cette version, Firefox (et Chrome aussi) arrête de faire confiance aux certificats signés par StartSSL après la date du 21 octobre 2016. Il se trouve, que deux de mes sous-domaines étaient concernés. Je me suis donc (re)plongé dans la documentation de certbot, pour découvrir l’outil et effectuer mes premiers tests.

L’ensemble a plutôt bien évolué par rapport à ce dont je me souvenais. Après plusieurs relectures et quelques tests, j’ai abouti à une procédure qui me convient. J’effectue donc la première demande de certificat manuellement, en conservant pour le moment l’isolation des sous-domaines qui m’avait été imposées par StartSSL. Je conserve ainsi une certaine liberté si je décide de migrer un service d’un serveur vers un autre. Je suis également arrivé à la configuration commune suivante, que je déploie à l’emplacement attendu par certbot, à savoir /etc/letsencrypt/cli.ini :

# Certbot Config

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

# Register with the specified e-mail address
email = <e-mail>

# Use the standalone authenticator on port 80
authenticator = standalone
preferred-challenges = http-01

De cette manière, la demande d’un nouveau certificat pour un domaine reste concise, il n’est plus nécessaire de renseigner tous les paramètres du fichier de configuration et on obtient donc par exemple :

certbot-auto certonly -d www.unicoda.com

Une fois le certificat généré, les lignes suivantes sont nécessaires du côté d’Apache :

SSLCertificateFile /etc/letsencrypt/live/<domaine>/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<domaine>/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/<domaine>/chain.pem

Redémarrage d’Apache que l’on avait arrêté le temps d’effectuer la procédure de demande de certificat et ça y est le navigateur affiche un fabuleux « Vérifié par : Let’s Encrypt ».

Du côté du renouvellement, je vais passer par la crontab pour qu’une vérification quotidienne des certificats soit effectuées. Le programme certbot s’occupant d’arrêter puis de redémarrer Apache :

certbot-auto renew --quiet --pre-hook "service apache2 stop" --post-hook "service apache2 start"

En théorie, le renouvellement automatique est donc en place, et le moment venu, les anciens certificats devraient être remplacés par des nouveaux sans que cela ne bouleverse (trop) le fonctionnement du site. Comme nous ne sommes jamais à l’abri d’une erreur de configuration malgré les nombreuses vérifications effectuées, et que je ne pourrais en être sûr qu’une fois les nouveaux certificats en place, je vous donne rendez-vous aux alentours du 26 mai 2017, date d’expiration du premier certificat Let’s Encrypt pour www.unicoda.com. Normalement, l’opération devrait être transparente pour tous, et je me réveillerais donc un matin (beau de préférence) avec un certificat tout neuf, sans avoir rien eu à faire.

Il ne reste plus qu’à patienter.

Téléphone, sécurité et mise à jour. C’est le bordel…

Mon téléphone actuel est un Xperia Z1 de marque Sony. Première apparition sur le marché en 2013, j’utilise le mien depuis presque trois années, autant dire une éternité pour un téléphone « moderne ». J’ai arrêté les téléphones vendus par les opérateurs depuis un bout de temps : rien à cirer de la surcouche opérateur ajoutant son lot d’applications inutiles et difficiles, voir impossible à désinstaller. Dans le cas de mon Z1, nous étions donc sur un téléphone constructeur, que je n’ai pas tardé à rooter, pour y faire tourner une ROM alternative, en l’occurrence CyanogenMod en version Nightly et en partie libérée de Google avec freecygn.
Que dire de plus si ce n’est que, pour le moment, il fonctionne parfaitement. Mais, …

Car il y a bien un mais. Le constructeur a arrêté les mises à jour d’Android à la version 5.0.2 en juin 2015 soit à peine plus de 2 ans après la sortie du téléphone. Au revoir mise à jour de sécurité via le canal officiel.  A cette époque, je faisais encore le malin puisque je venais de mettre à jour Cyanogen vers sa version 12-1 soit un Android 5.1.1. C’est ici que s’arrête l’histoire pour les mises à jour. Quelques commits ont eu lieu sur une branche cm-13.0 du dépôt Git, mais pas de builds officiels. Et cela ne risque pas de s’améliorer puisque CyanogenMod a cessé d’exister en décembre 2016. La communauté a repris le projet sous le nom LineageOS, mais l’âge du téléphone n’y changera rien, il y a peu de chance que j’obtienne un binaire pour mettre à jour ou remplacer mon système vers une version récente d’Android.

En parallèle, de nombreuses failles qui se sont succédées, surtout pour 2016, parmi lesquelles de nombreuses failles critiques. Youpi, mon téléphone est donc tout troué du point de vue de la sécurité. Du côté d’Android, il faut noter que nous sommes face à un système qui se ferme de plus en plus. L’article The proprietarization of android google play services and apps nous apprend par exemple que de nombreuses fonctionnalités de base, sont progressivement déplacées du système en lui-même vers le Google Play Services. Il devient alors toujours plus difficile de faire fonctionner des applications sans ce composant, si on a fait le choix de s’en passer, ou si le système ne l’intègre pas (Jolla Sailfish, …). Une alternative semble toutefois se dessiner avec le projet microG.

Bref, je n’ai pas envie d’acheter un nouveau téléphone au prix d’un ordinateur, alors que mon téléphone actuel continue de fonctionner. Du côté sécurité, Apple ne semble pas s’en tirer trop mal, mais les prix sont prohibitifs et je reste réfractaire à l’environnement IOS qui vient avec.

Quelles alternatives alors ?

  • Qu’on ne me parle pas de Windows Phone. Ça ne me tente pas du tout. Les ajouts de type surveillance de l’utilisateur me disent de rester loin de la plateforme mobile de Microsoft en tant qu’utilisateur.
  • Un téléphone chinois pour moins de 100E ? Pourquoi pas, mais à condition d’être certain qu’il n’y ai pas de backdoor. Par ailleurs, le problème des mises à jour n’arrivant plus risque de rester le même et on se retrouve donc à jeter un appareil fonctionnel pour faire tourner la machine économique. On garde donc dans un coin l’idée du téléphone chinois de transition à prix réduit; avec le moins possible de Google dedans ou en remettant une custom rom directement.
  • Le Neo900 encore en cours d’élaboration. Principe très attractif car séparation matérielle du modem et du CPU, l’alimentation du modem pouvant être désactivée (si j’ai bien suivi). Relativement inaccessible de par son prix (Environ 990E , même si réparti sur plusieurs années, cela pourrait se justifier). OS disponible relativement flou pour l’instant. Quelles possibilités ?
  • Dans la même idée, le GTA04.
  • Jolla. Les infographies semblaient proposer quelque chose d’un peu nouveau. Ils se sont plantés avec les tablettes, donc ils se concentrent sur le soft. Une base Linux. Plus de stock de téléphone au moment où j’écris ces lignes. Une entreprise indienne a produit quelques téléphone embarquant le système d’exploitation Jolla pour le marché indien. La poste Russe a annoncé vouloir acquérir des téléphones tournant sous Sailfish OS.
  • Ubuntu Phone. Pas vraiment de stock.
  • Une Fairphone ? Un téléphone plus « éthique » dans ses choix, pourquoi pas, mais le problème de version reste le même. Ici, du Android 5.1. Pour le prix, compter au moins 500E.
  • Construire sa propre ROM en se basant sur AOSP et sur la documentation Sony. Cela semble plutôt bien expliqué et cela me permettrait de mettre en application ce que j’avais eu l’occasion d’apprendre en cours.

Bref, beaucoup de solutions envisageables. Et pourtant, il n’y en a pas une qui me satisfait plus que les autres. D’ailleurs, plus j’y pense et et plus l’idée de mettre les mains dans le cambouis m’attire. Je vois d’ici les heures de travail pour préparer l’environnement de développement, adapter et compiler les sources, puis tester. Le résultat est incertain, l’échec possible, mais voyons le bon côté des choses, la documentation du constructeur semble plutôt complète, il existe quelques dépôts libres sur Github et je ne pars pas de zéro puisque j’ai eu la chance de suivre un cours sur le sujet durant mes études d’ingénieur (LO52 – Merci Fabien !). J’ai donc commencé à lire la documentation et à parcourir les forums, notamment XDA pour mon modèle de téléphone, et ce qu’on peut y lire a de quoi refroidir. A priori, en passant à Android 7, il y a un risque non nul de se retrouver avec un port micro-usb ne rechargeant plus la batterie du téléphone, ce qui est quand même un inconvénient majeur. Par ailleurs, ce qui m’ennuie le plus, c’est d’être obligé de tester directement sur le téléphone que j’utilise quotidiennement. L’idéal serait de mettre la main sur un deuxième exemplaire du téléphone à peu près en état de marche afin de disposer d’une plateforme de test.

Finalement, le problème est intrinsèquement lié au fonctionnement actuel de notre société, basée sur une consommation de masse permanente. Dans ce contexte, un constructeur renouvelle complètement sa gamme en 2 à 3 ans. Au revoir support sur les anciens modèles, les équipes sont assignées à la maintenance de la gamme en cours. Obsolescence par le logiciel donc, le matériel évoluant assez peu, mise à part les ajouts de RAM, puissance de calcul ou nombre de pixel de l’appareil photo. Tout cela pour vider la batterie plus rapidement, bien évidemment.

Pour ma part, je vais donc garder mon téléphone en Android 5.1 pour l’instant et voir comment les choses évoluent.

Mettre à jour des certificats sur une machine Windows non connectée

Il y a plusieurs semaines, j’ai rencontré un problème original dans mon travail quotidien. Ayant à effectuer des modifications sur du code en .NET servant d’intermédiaire entre deux composants, j’avais besoin de connaître les données en entrée et en sortie d’une partie du programme. Petite subtilité, avec l’interconnexion des composants, il me semblait plus aisé d’utiliser le débogage à distance du code.

Premier problème, les outils de débogage déjà installés sur la machine ne sont pas compatibles avec ma version de Visual Studio. Je me rends donc sur la page des téléchargements pour Visual Studio afin de récupérer l’exécutable « Remote Tools for Visual Studio 2015 Update 3 ». Celui est dissimulé dans le tableau en milieu de page, après avoir déplié la catégorie « Tools for Visual Studio 2015 », on accède au téléchargement des « Outils de contrôle à distance de Visual Studio 2015 Update 3 ».

Transfert de l’exécutable sur la machine serveur concernée, exécution. Après quelques minutes d’attentes, une erreur apparaît, les certificats présents sur la machine ne permettent pas de vérifier et valider l’installation. Je vérifie les paramètres réseau du serveur, pas de chance, connexion au réseau local seulement, pas de possibilité de mettre à jour les certificats via internet.

Après quelques recherches, je tombe sur cette procédure de la documentation Microsoft, et pour une fois, celle-ci me semble plutôt complète. L’idée : récupérer les certificats de mon poste de développement et les importer sur la machine serveur. Voici la procédure que j’ai suivie (extrait de la doc).

Dans une console en mode administrateur :

Certutil -generateSSTFromWU WURoots.sst
start explorer.exe wuroots.sst

Le gestionnaire de certificats de la machine s’ouvre.

  • Dans le volet de navigation du gestionnaire, développer le chemin d’accès au fichier sous Certificats – Utilisateur actuel jusqu’à ce que Certificats s’affiche, puis cliquer sur Certificats.
  • Dans le volet d’informations, les certificats de confiance s’affichent. Maintenir la touche CTRL enfoncée et cliquer sur chacun des certificats à autoriser. Une fois la sélection des certificats à autoriser terminée, clic droit sur l’un des certificats sélectionnés, cliquer sur Toutes les tâches, puis sur Exporter.
  • Dans l’Assistant Exportation du certificat, cliquer sur Suivant.
  • Dans la page Format du fichier d’exportation, sélectionner Magasin de certificats sérialisés Microsoft (.SST), puis cliquer sur Suivant.
  • Dans la page Fichier à exporter, entrer un chemin d’accès au fichier et un nom approprié pour le fichier, par exemple C:\AllowedCerts.sst, puis cliquer sur Suivant. Cliquer sur Terminer. Cliquez sur OK après avoir été informé de la réussite de l’exportation.

Après avoir transféré notre fichier AllowedCerts.sst sur la machine cible, on peut s’intéresser à l’import des certificats.

Pour cela, il est nécessaire de se rendre dans le « Panneau de configuration » de la machine, puis « Option internet » et aller à l’onglet « Contenu » dans la fenêtre qui s’affiche. Enfin, cliquer sur le bouton « Certificats ».

Dans la fenêtre « Certificats » :

  • Cliquer sur le bouton « Importer ».
  • Choisir le fichier en modifiant la liste d’affichage par type de fichier vers .sst.
  • Choisir la sélection automatique du magasin de certificat selon le type de certificat.
  • Cliquer sur « Terminer ».
  • Valider (Oui) pour chaque certificat.

Pour finir, relancer l’installation des outils de contrôle à distance. Si les certificats de la première machine était bien à jour, l’installation devrait s’effectuer correctement. Il est toutefois dommage que le ou les certificats manquants à l’installeur ne soient pas clairement désignés, cela nous aurait permis de ne sélectionner que les certificats nécessaires et non d’intégrer sans distinction tous les certificats présents sur la machine source.