Attempting to renew cert failes

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: www.deverbinding.nu

I ran this command: I don’t know

It produced this output: Attempting to renew cert (www.deverbinding.nu) from /etc/letsencrypt/renewal/www.deverbinding.nu.conf produced an unexpected error: Failed authorization procedure. www.deverbinding.nu (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://deverbinding.nu/ .well-known/acme-challenge/S9MsuYJ8uuuGycJncIqJFksgkdCD5rr6QqG3VR_llLM [2a00:d640:d640:9999::2eeb:286e]: “\n<html lang=“nl”>\n\n<meta charset=“UTF-8” />\n\n<link rel=“profile” href=[“https://gmpg.org/xfn/11”](https://gmpg.org/xfn/11) />\n<link re”. Skipping. Attempting to renew cert (deverbinding.nu) from /etc/letsencrypt/renewal/deverbinding.nu.conf produced an unexpected error: Failed authorization procedure. deverbinding.nu (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://deverbinding.nu/ .well-known/acme-challenge/hGXgIl_vVV9h-xUSVrjw2Tcn8i4Y0m6A3Qsl4X5x3Os [2a00:d640:d640:9999::2eeb:286e]: “\n<html lang=“nl”>\n\n<meta charset=“UTF-8” />\n\n<link rel=“profile” href=[“https://gmpg.org/xfn/11”](https://gmpg.org/xfn/11) />\n<link re”. Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/www.deverbinding.nu/fullchain.pem (failure) /etc/letsencrypt/live/deverbinding.nu/fullchain.pem (failure) 2 renew failure(s), 0 parse failure(s)

My web server is (include version): moved

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

Good afternoon, my husband was a letsencrypt-fan and ran a server, where we hosted www.deverbinding.nu. He died, over a year ago now, and I moved the website to another server, from a host who provides SSL-certificates. Since then I get daily emails from our own server, that the attempts to renew the cert of www.deverbinding.nu fail. I thought it didn’t matter, but we have trouble to reach the website now: browser are notifying us that it’s not a secure site.

Can you assist me, to find the script that tries to renew the cert?

Kind regards,
Joke Portegies

1 Like

Hoi Joke,

Allereerst gecondoleerd met je verlies.

Inhoudelijk: vanuit mijn browser (Chrome) is de site www.deverbinding.nu weldegelijk beveiligd: het heeft een groen slotje zonder dat die verandert in een uitroeptekentje of iets dergelijks. Wat voor melding krijg jij? Graag het liefst een screenshot en duidelijke uitleg wat je gedaan hebt om het zo te krijgen.

Verder heeft je site een certificaat die op 2 december 2019 is gegenereerd en pas in maart verloopt. Het is dan ook volgens de ongeschreven regels nog helemaal niet nodig om te vernieuwen (da’s pas binnen 30 dagen van de verloopdatum).

Ik dénk dus dat je nieuwe hosting provider inderdaad gewoon het TLS-certificaat voor z’n rekening neemt. Blijven 2 dingen over:

  1. Waarom werkt de site bij jou niet goed?
  2. Waarom krijg je nog dagelijkse emails?

T.a.v. 1 heb ik hierboven al om een screenshot e.d. gevraagd. T.a.v. 2: krijg je de e-mails van je oude server of van je nieuwe hosting? Het feit dat je zegt dat je nieuwe hosting provider de TLS-certificaten voor z’n rekening zou moeten nemen, zegt mij dat je geen “root toegang” via SSH/shell hebt en dat eventuele instellingen voor je site via een of ander controle-paneel (zoals cPanel) gaat.

Mocht het je oude server zijn die de meldingen maakt (en dat denk ik van wel), dan is dat logisch: hij probeert naar zichzelf te verbinden (de oude server), maar komt uit bij je nieuwe server, waarbij die nieuwe server van niets weet. En hoogst waarschijnlijk hoeft je oude server helemaal niets meer te doen met Let’s Encrypt-certificaten. Tenzij er natuurlijk nog meer sites op die oude server draaien die niet overgezet zijn op andere webhosting. Maar daar kun jij wellicht een antwoord op geven.

Dank je, Osiris, voor je uitgebreide antwoord.
Op vraag 1 heb ik inmiddels antwoord: we benaderden de site vanuit een andere computer dan ik gewend ben. Via m’n eigen laptop heb ik een aanpassing gemaakt in het hosts-bestand om voor deze site een ander IP-adres te benaderen. Er is iets met de beveiliging hier in huis, waardoor dat kennelijk nodig is.
Op vraag 2 kan ik je zeggen dat ik inderdaad vermoed dat de emails door de oude server worden gegenereerd en het gaat alleen over deze ene website, waar dus inderdaad niets voor gedaan hoeft te worden. Ik ben computervaardig, maar niet zo Linux-vaardig. Kun je me een hint geven, waar ik zoeken moet om dit uit te zetten?
Hartelijke groet

Ligt er aan welke variant van Linux het is. Distributies gebaseerd op Debian hebben een zogenaamde “systemd timer” draaien. CentOS/Redhat weet ik eerlijk gezegd niet, kan een systemd timer zijn of een cronjob.

Als je systeem systemd draait, zou je met systemctl list-timers (uitvoeren als root) eventueel een verwijzing certbot moeten kunnen zien. Waarschijnlijk zou deze dan met systemctl disable certbot.timer uitgeschakeld moeten kunnen worden.

Als je bij bovenstaande geen certbot tegenkomt, dan zou je kunnen kijken of er een cronjob draait d.m.v. crontab -e uit te voeren (als root). Als je daar een certbot-verwijzing tegenkomt, kun je deze uitschakelen door een hekje (#) aan het begin van de zin waar certbot in voorkomt te zetten.

Heel hartelijk dank. Dit klinkt doable. Ik ga me er toe zetten!
Joke

1 Like