Let’s Encrypt est une autorité de certification fournissant des certificats SSL depuis 2016. Une des raisons de son succès est que les certificats étaient indirectement signés par l’autorité de certification IdenTrust préinstallée dans la plupart des navigateurs. Petit à petit, le certificat racine de Let’s Encrypt a été intégré dans les navigateurs et systèmes d’exploitation, et nous voici arrivés au jour où Let’s Encrypt aurait dû prendre son envol : le jeudi 30 septembre 2021 à 16h où le certificat DST X3 d’Identrust expire.

Sauf que ce décollage est plus compliqué que prévu car Let’s Encrypt a décidé de conserver dans sa chaîne de certification un certificat intermédiaire signé par ce certificat Identrust expiré pour conserver jusqu’en 2024 la compatibilité avec Android 7 et inférieur (environ 4% du trafic web mondial).

La conséquence pour les clients HTTPS est qu’il faut s’assurer qu’openssl est assez récent (les dernières version d’openssl sont moins strictes sur la vérification des expirations) ou alors on peut contourner le problème en supprimant ce fameux certificat DST X3 dans la base locale de certificats CA. Concrètement sur les serveurs Linux, on commente la ligne mozilla/DST_Root_CA_X3.crt dans le fichier /etc/ca-certificates.conf (puis on met à jour sa base de certificats CA et on recharge les démons susceptibles de l’utiliser).

La conséquence pour les serveurs HTTPS est plus subtile : soit on garde le certificat intermédiaire signé par le certificat DST X3 expiré afin de prolonger la compatibilité avec Android 7 et inférieur, soit on supprime ce certificat intermédiaire afin de conserver la compatibilité avec des vieux clients HTTPS que l’on ne maîtrise : des clients en ligne de commande (curl, wget, etc.), du Java pas à jour, du PHP sur un système pas à jour, des clients d’API, des callbacks de paiement, etc.

Liens pour en savoir plus :

• https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
• https://letsencrypt.org/certificates/
• https://www.identrust.com/dst-root-ca-x3-cross-signing-identrust-commercial-ca-1-chain-details
• https://www.octopuce.fr/letsencrypt-certificate-expiration-consequences/

Dans le cadre de nos missions d’hébergement et d’infogérance, nous proposons naturellement des dispositifs de sauvegardes des infrastructures que nous gérons.

Sauvegarde Evolix et sauvegarde tierce
Nous disposons d’une infrastructure de sauvegarde interne, basée sur des groupes de serveurs, répartis dans des centres de données éloignés géographiquement (au moins plusieurs kilomètres). Sur cette infrastructure nous proposons un dispositif de sauvegarde à tous nos clients,  inclus dans le forfait ou optionnel selon les offres.

Système « evobackup »
Par défaut, nous organisons notre système de sauvegarde avec une partie configurée sur les serveurs d’origine et une autre partie sur les serveurs de sauvegarde.
Sur le serveur d’origine un script est exécuté quotidiennement (ou plus). Il commence par préparer des données à sauvegarder (collecte d’informations d’état, export de bases de données…) puis va synchroniser ses données locales vers le serveur de sauvegarde.
Si plusieurs serveurs de sauvegarde sont disponibles, une rotation des serveurs se produit. Par exemple, avec 2 serveurs de sauvegarde il y aura les sauvegardes des jours pairs sur un serveur et les jours impairs sur l’autre serveur. En cas de défaillance d’un serveur du groupe de sauvegarde, le script bascule sur un autre. Si aucun serveur n’est disponible, une alerte est déclenchée.
Sur le serveur de sauvegarde il y a un point d’entrée réservé (filtrage par IP et clé SSH) vers une zone de stockage dédiée (appelée « jail » en interne) à chaque serveur où celui-ci peut envoyer ses données (quelles qu’elles soient).
Chaque jour, une copie datée (appelée « inc » en interne) de cette zone de stockage est effectuée, dans un espace inaccessible au serveur d’origine (pour sécuriser l’accès aux données historisées). Le nombre de copies datées conservées dépend de la politique de rétention des données qui est décidée. Nous gardons au moins les 5 derniers jours et le 1er jour des 3 derniers mois, mais cela peut être configuré spécifiquement pour chaque « jail ». Chaque jour, les copies datées qui sortent de cette politique de rétention sont supprimées.

Autres modes de sauvegarde
Au delà du système « evobackup » que nous mettons en œuvre habituellement, il est possible de configurer d’autres systèmes de sauvegarde, s’ils sont bien compatibles avec nos contraintes. Cela peut être des agents de sauvegarde à installer sur le serveur. Pour les infrastructures virtualisées ça peut être une sauvegarde bas niveau.

Sauvegarde « système » vs. « complète »
Nous considérons que pour faire notre métier correctement il est indispensable d’avoir à tout moment au moins une sauvegarde des éléments du système. C’est pour cela que (sauf rares exceptions) nous mettons systématiquement en œuvre une sauvegarde des éléments clés du système.
Ces sauvegardes systèmes comprennent : /root /boot /etc /var (avec des exclusions) /usr (avec des exclusions) /lib /bin et /sbin
Les exclusions typiques sont : les « datadir » des bases de données inexploitables à chaud (MySQL, PostgreSQL, Elasticsearch…), les fichiers temporaires, les caches et fichiers d’état de services qui sont inexploitables à chaud (/var/lock, /var/state …) et les journaux système (/var/log)
Dans les sauvegardes « système » nous excluons par défaut toutes les données applicatives et métier des serveurs. Cela concerne typiquement /home (données utilisateurs), /srv (données applicatives)… Ces données ne sont sauvegardées que lorsqu’on fait une sauvegarde complète.

Cas de figure 1 : Cloud Public Evolix et Logiciels Libres en SaaS
Si vous utilisez des serveurs virtuels installés dans le Cloud Evolix (appelés « EvoVM ») ou des Logiciels Libres en SaaS, votre forfait comprend d’office une sauvegarde complète vers notre plateforme redondante de sauvegarde. Cela comprend donc toute la partie sytème mais aussi les données applicatives et métier.

Cas de figure 2 : Serveurs dédiés et Cloud Privé
Si vous utilisez des serveurs autonomes ou un Cloud Privé – qu’ils soient hébergés chez Evolix ou chez un hébergeur tiers – vous avez d’office une sauvegarde système vers notre plateforme redondante de sauvegarde. Nous pouvons activer une sauvegarde complète en option. Elle est facturée au volume, donc dépend de la quantité de données stockées et de la politique de rétention choisie.

Cas de figure 3 : Serveur(s) de sauvegarde dédié(s)
Nous proposons également la mise en place de serveurs de sauvegarde dédiés. Ils peuvent être hébergés chez Evolix ou chez des hébergeurs tiers. Ils sont installés d’une manière spécialisée et ne peuvent être utilisés que pour des sauvegardes et ne sont par défaut pas accessibles en dehors de nos équipes.
Nous conseillons d’éloigner les serveurs de sauvegarde des serveurs à sauvegarder. Nous conseillons également d’avoir au moins 2 serveurs de sauvegarde. En effet, la panne peut aussi bien toucher les serveurs de sauvegarde, notamment les disques qui sont fortement sollicités tous les jours. En disposant de deux serveurs de sauvegarde, si l’un d’eux est perdu, l’historique des données n’est pas perdu.