Impossible to renew letsencrypt cert : La signature du nouveau certificat a échoué

My YunoHost server

Hardware: LXC container, self-hosted, Debian Stretch hypervisor
YunoHost version: 3.6.4.3
I have access to my server : Through SSH | through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : not realy (regen-conf is clean except for resolvconf and some dnsmasq, which does not seem relevant here at first glance)

Description of my issue

My ynh server is yelling at my mailbox since several days because it cannot renew a cert on one domain (others are fine). Let’s call it mail.internet.boss

This domain hosts only a roundcube instance, at domain root.

So I tried to tackle the issue, found this topic, and tried to re-install the cert (with or without temporary going through a self-signed and then back to LE).

The installation of new cert fails the same way as cert renewing :

2019-10-02 22:42:05,932: DEBUG - Now using ACME Tiny to sign the certificate...
2019-10-02 22:42:05,932: INFO - Parsing account key...
2019-10-02 22:42:05,942: INFO - Parsing CSR...
2019-10-02 22:42:05,953: INFO - Found domains: mail.internet.boss
2019-10-02 22:42:05,953: INFO - Getting directory...
2019-10-02 22:42:06,766: INFO - Directory found!
2019-10-02 22:42:06,767: INFO - Registering account...
2019-10-02 22:42:08,411: INFO - Already registered!
2019-10-02 22:42:08,412: INFO - Creating new order...
2019-10-02 22:42:10,067: INFO - Order created!
2019-10-02 22:42:10,869: INFO - Verifying mail.internet.boss...
2019-10-02 22:42:10,873: ERROR - Wrote file to /tmp/acme-challenge-public/X3ccdxfnXdBU28rZxpKgi6hQnW4Z6zDnhvKAlOtpI4, but couldn't download http://mail.internet.boss/.well-known/acme-challenge/X3ccdxfnXdBU28rZxpKgi6hQnW4Z6zDnhvKAlOtpI4: Error:
Url: http://mail.internet.boss/.well-known/acme-challenge/X3ccdxfnXdBU28rZxpKgi6hQnW4Z6zDnhvKAlOtpI4
Data: None
Response Code: 403
Response: <html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>

2019-10-02 22:42:11,143: WARNING - Debug information:
 - domain ip from DNS        89.X.Y.Z
 - domain ip from local DNS  192.168.ZZ.TT
 - public ip of the server   89.X.Y.Z

2019-10-02 22:42:11,406: WARNING - Debug information:
 - domain ip from DNS        89.X.Y.Z
 - domain ip from local DNS  192.168.ZZ.TT
 - public ip of the server   89.X.Y.Z

2019-10-02 22:42:11,407: ERROR - Certificate installation for mail.internet.boss failed !
Exception: La signature du nouveau certificat a échoué


A workaround I found :

mv /etc/nginx/mail.internet.boss.d/roundcube.conf /tmp/roundcube.conf
systemctl restart nginx
yunohost domain cert-install mail.internet.boss --force
mv  /tmp/roundcube.conf /etc/nginx/mail.internet.boss.d/roundcube.conf
systemctl restart nginx

But i’d need to do it every two months :-(.

Any ideas to help me solve it properly ?

<3 by now and by advance.

Hmmmm does yunohost tools regen-conf --dry-run -d complains that some files needs to be updated ? (like the nginx conf of this domain or the dnsmasq config (considering that this “domain ip from local DNS” shouldn’t be a 192.168 ip ?))

Thanks for your answer !

yunohost tools regen-conf --dry-run -d

Yes, /etc/resolv.dnsmasq.conf : I overrided the DNS server, on purpose, to
handle hairpining issues nicely. Can it be linked to that
malfunction ?

(except that, no conf file dirty).

Bonjour,
Je pense comme @Aleks que IP from local DNS devrait être 89.X.Y.Z, si c’est votre adresse publique !
Peut-être sauvegarder la conf DNS et faire

Puis relancer le renouvellement du certificat.
Je ne suis pas un spécialiste, aussi, attendre voir si @Aleks est OK avec cette méthode :slight_smile:

Hmmmm je sais pas ça m’a l’air relativement legit d’avoir modifié dnsmasq de cette manière, ca devrait pas interferer.

Du coup, vu que enlever/remettre le bout de conf roundcube semble regler le soucis, ça ressemble à un soucis de regle nginx qui prends le dessus sur la regle de roundcube … J’imagine que c’est parce que l’app est installé à la racine mais je pensais que ce genre de soucis était réglé … (du coup mon pronostique était + sur une conf nginx pas nominale)

Brefle heu beh je serais curieux de voir les bouts de conf de nginx pour roundcube et d’essayer de comprendre pourquoi ça pamarch… Je m’demande si ce vieux coup du 000-acmechallenge.conf qui trained dans domaine.tld.d/ est vraiment cool ou si on devrait pas inclure le snippet directement dans la conf nginx même si je doute que ça change vraiment grand chose.

Est-ce que tu peux confirmer que ton 000-acmechallenge.conf contient bien ceci exactement ?

Sinon, eventuellement est-ce qu’il a des trucs particuliers (genre redirection) dans /etc/ssowat/conf.json.persistent ?

J’ai ça :

location '/.well-known/acme-challenge'
{
        default_type "text/plain";
        alias /tmp/acme-challenge-public/;
}

J’ai ça :

{
    "skipped_urls": [
        "code.internet.boss/"
    ]
}

(c’est un domaine différent de celui qui dysfonctionne pour LE)

Du coup a mon avis il manque le ^~ (cf. ici) qui permet de preciser à nginx que c’est cette règle à utiliser en priorité par rapport au location / de Roundcube …!

Dommage qu’on ai pas automatiquement migré ce fichier …

1 Like

Wahou, bien vu, un gros merci !

Une idée de commetn faire

Pff, trop fort, un gros merci !

Pour toute personne qui tomberait sur cette discussion, j’ai pu valider la solution en forçant le renouvellement grace à :

 yunohost domain cert-renew --force --email mail.internet.boss

@Aleks j’imagine que c’est intéressant de faire la même modif sur tous les 0000-acmechallenge.conf ?

Ouaipe

For lazy like me, the one-liner to fix the 0000-acmechallenge.conf files :

sudo sed -i "s@'/.well@ ^~ '/.well@g" /etc/nginx/conf.d/*/000-acmechallenge.conf
sudo systemctl reload nginx
1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.