L’erreur « trop de certificats »

Je pense que cela met une instance de Discourse hors service. Elle ne parvient pas à passer le message de forte charge « Oops… ».

Create new order error. Le_OrderFinalize not found. {

  "type": "urn:ietf:params:acme:error:rateLimited",

  "detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ....

Je vois que d’autres ont rencontré ce problème pour une raison ou une autre, mais existe-t-il une solution ?

Je pense qu’il te suffit d’attendre quelques heures et de réessayer. Si ma mémoire est bonne, la limite de débit se réinitialise à chaque heure. Tu pourrais aussi demander un préfixe www sur le nom de domaine pour obtenir un nouveau certificat et réinitialiser le compteur.

Merci pour l’indication. Je vais essayer de reconstruire maintenant, car cela fait quelques heures.

Il s’avère que l’attente est de 7 jours selon @Ed_S ici !

La reconstruction n’a pas fonctionné.

J’ai relancé l’assistant de configuration pour ajouter www afin d’obtenir un nouveau certificat. Cela a semblé fonctionner, mais j’ai dû suivre la suggestion de @pfaffman pour désactiver la vérification de la connexion, contournant ainsi l’erreur d’inaccessibilité du port 443.

Maintenant, l’application du certificat échoue, d’après les journaux :

...PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)

Cela pourrait être lié au problème des ports 443/80 fermés, qui est un autre problème que je vois et qui semble courant.

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      72556/docker-proxy

tcp6       0      0 :::443                  :::*                    LISTEN      72564/docker-proxy

En scannant les ports via un vérificateur externe, ils apparaissent fermés :man_shrugging:

D’accord, je suis revenu sur un autre serveur avec une version restaurée de la base de données, où les ports 80/443 étaient ouverts. J’ai vérifié à l’aide d’un analyseur de ports externe avant de continuer.

Lorsque j’ai exécuté ./launcher discourse-setup, l’erreur « port 443 inaccessible » s’est produite.

J’ai donc rescané le serveur sur les ports 80 et 443, et ils apparaissent maintenant comme fermés.

C’est comme si l’exécution de l’assistant fermait les ports ?! :man_shrugging:

Je ne pense pas que l’assistant prenne en charge plusieurs noms de domaine, mais je ne l’ai pas utilisé depuis longtemps.

C’est presque certainement votre problème. Vous n’avez probablement pas configuré le DNS ou bien quelque chose bloque le trafic entrant.

Salut, merci, oui j’ai réussi à résoudre l’erreur PEM_red… mentionnée plus haut en annulant « grey clouds ». J’ai trouvé le conseil dans un autre sujet.

Lors de l’exécution de l’assistant, j’ai simplement saisi le domaine www. Est-ce que c’est une erreur de le faire ? C’était pour contourner la limite de débit.

Bref, après cette erreur PEM, je suis arrivé à celle-ci :

fail: nginx: runsv not running

[Wed Sep .... UTC 2026] Reload error for :

C=US, O=Let's Encrypt, CN=YR1

error 2 at 1 depth lookup: unable to get issuer certificate

error fullchain.cer: verification failed

C=US, O=Let's Encrypt, CN=YE2

error 2 at 1 depth lookup: unable to get issuer certificate

error fullchain.cer: verification failed

Cependant, cela ressemble à un problème mineur, car il y a une série de sorties de succès de certificat dans les journaux qui ne se produisaient tout simplement pas avant que je n’active « grey clouds ».

Les ports 80 et 443 sont également affichés comme ouverts.

Je vois aussi ceci affiché plusieurs fois à la fin des journaux :

X-Accel-Mapping header missing

Laissez-moi ajouter plus de contexte : l’instance résout le domaine et autorise la connexion, donc l’écran de connexion apparaît (configuré pour la connexion uniquement) et accepte les identifiants et la double authentification, puis, une fois que cela a réussi, on revient à l’écran « Oops… » de « oh not again ».

Ce qui signifie que je suis revenu à mon point de départ.

À l’origine, rien sur l’instance du serveur d’origine n’avait été modifié. Soudain, il y a eu quelques jours de comportement non performant, pendant lesquels les métriques affichaient une charge cyclique du serveur anormale au-delà des niveaux normaux. Comme si le moteur tournait à plein régime sans avancer, jusqu’à ce qu’il finisse par s’effondrer dans un état permanent de « Oops ».

J’ai donc commencé à y travailler. Une solution a été de sauvegarder et de restaurer sur un nouveau Discourse, ce qui est l’état actuel des choses, c’est-à-dire capable de se connecter mais de retour à « Oops ».

Note historique également : j’ai eu des problèmes avec Full ou Full (strict) par le passé. Full (strict) n’a pas toujours fonctionné et j’ai dû revenir à Full. Cela peut être anecdotique.

Oh là là :worried:

D’accord, je peux confirmer que ça a fonctionné. J’ai utilisé un ancien utilisateur non administrateur et je peux me connecter.

On a tourné en rond alors que c’était apparemment le problème tout du long !