Aller au contenu

Comment l'incident de Let's Encrypt m'a obligé à aller grenouiller dans la base sqlite de mon NPM (Nginx Proxy Manager)

Bonjour,

Alors que je tentais de créer un nouveau service dans NPM (Nginx Proxy Manager) ce vendredi soir, tout a bloqué des suites d’un incident sur les serveurs de production de lets’ Encrypt 1.

Après que leur service soit rétabli, j’ai voulu reprendre mon travail normalement et là, patatras !

Plus rien ne fonctionnait comme il faut.

J’ai dû ouvrir le capot et rentrer dans le moteur pour rétablir le bon fonctionnement de mon système :

  • supprimer les certificats créés après la panne dans les dossiers archive, sans oublier les liens dans live ;
  • supprimer leurs fichiers de configuration dans renewal ;
  • rentrer dans la base database.sqlite pour vérifier les tables et supprimer les enregistrements orphelins ou mal configurés.

Pour accéder à la base de données sqlite, j’ai utilisé un sqlite3 installé sur le serveur hôte car le conteneur n’en proposait pas.

Pour mémoire, voici quelques commandes utiles à connaître une fois dans la base via sqlite3 database.sqlite :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
.headers on
.mode columns
-- Lister les hosts
SELECT id, domain_names, certificate_id, is_deleted FROM proxy_host;
-- Si besoin, uniquement les hosts actifs
SELECT id, domain_names, certificate_id FROM proxy_host WHERE is_deleted = 0;
-- Ou cibler un host en particulier
SELECT id, domain_names, is_deleted FROM proxy_host WHERE id = 666;
-- Lister les certificats
SELECT id, nice_name, domain_names, expires_on FROM certificate;
-- Suppressions sélectives
DELETE FROM proxy_host WHERE id = 666;
DELETE FROM certificate WHERE id = 666;
-- Quitter sqlite
.exit

Addendum : 9 mai 2026
#

Je pensais avoir tout mis au propre en « purgeant » tout ce que je pouvais trouver d’incohérent et postérieur au plantage de Let's Encrypt, que nenni !

Je m’aperçois que les indices de host et des noms de dossiers pour le stockage des certificats sont décalés.

Quand NPM crée un certificat en l’identifiant #666 dans l’interface, il crée un dossier npm-667.

On peut vivre comme ça, mais c’est franchement pénible.

Comme je ne connais pas suffisamment l’intérieur de l’engin, je suis coincé pour le moment.

La seule solution viable que je vois à l’horizon va être de refaire une installation propre et de tout remettre en place ex nihilo.

Avis aux développeurs·ses
#

Quand on travaille sur des processus multi-tâches couches basses, on peut effectivement laisser chacun faire sa popote dans son coin, mais le « best effort » n’est pas suffisant pour bien faire. À un moment donné, il faut contrôler et resynchroniser tous ses petits. C’est mieux.

Au plaisir,

Marc JESTIN
https://marcjestin.fr