Error renewing certificate

Help
1

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:mail.mididoc.com

I ran this command:certbot renew --force-renewal

It produced this output:
acme.messages.Error: urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Error creating new order

2019-04-01 02:00:24,908:ERROR:certbot.renewal:All renewal attempts failed. The following certs could not be renewed:
2019-04-01 02:00:24,909:ERROR:certbot.renewal: /etc/letsencrypt/live/mail.mididoc.com/fullchain.pem (failure)
2019-04-01 02:00:24,909:DEBUG:certbot.log:Exiting abnormally:

My web server is (include version):Apache version 2.4.25

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

My hosting provider, if applicable, is:contabo

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

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

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

2

That's not supposed to happen...

Does it work if you try again?

Just curious, why not rely on "certbot renew"'s default behavior of renewing about every 60 days?

3

Hi @mike1950r

serverInternal looks like an internal Letsencrypt error. But your configuration may not work.

You have ipv4 and ipv6:

Host T IP-Address is auth. ∑ Queries ∑ Timeout
mail.mididoc.com A 91.194.90.24 yes 1 0
AAAA 2a02:c205:2005:4339::1 yes

But both addresses have a timeout:

Domainname Http-Status redirect Sec. G
• http://mail.mididoc.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
91.194.90.24 -14 10.026 T
Timeout - The operation has timed out
Visible Content:
• http://mail.mididoc.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a02:c205:2005:4339::1 -14 10.026 T
Timeout - The operation has timed out

So Letsencrypt isn't able to check the validation file in /.well-known/acme-challenge.

Your ipv4 answers with a redirect to port 8080. So the timeout of /.well-known/...:

  • it's a spam detection (or)
  • there are different rules / versus /.well-known
4

Hi Juergen,

thanks for your answer.
I have been able to automaticly renew my certificate all the last months.
The problem occured the first time, now.
If i use the command:
certbot renew --dry-run
get the output:

Processing /etc/letsencrypt/renewal/mail.mididoc.com.conf

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mail.mididoc.com
Waiting for verification…
Cleaning up challenges

new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/mail.mididoc.com/fullchain.pem

** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/mail.mididoc.com/fullchain.pem (success)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)

Nevertheless i got this error message in certbot log file.
If i look in webmin for the certificate it dispays valid till 30th.may.
so the renewal seems to be happened although i got the error message.

mail.mididoc is only accessible for directory:
/.well-known/acme-challenge/

this always worked file

this is because mail.mididoc does not content a website.
it’s a vps server with several sites.
mail.mididoc is only the main vps root.

BTW
as said it always worked.
but some days ago there was a certbot update on my debian9.

it seems that there has something changed till then.

hope this helps,
sorry my bad english.

best regards

mike

5

Then use

certbot renew --webroot certonly

to use the same parameters.

Perhaps you have used tls-sni-01 validation, now the new certbot (+ the test system) switches to another validation method.

6

When you see a serverInternal error, there's normally nothing that you can do to fix it. You should try again in a little while, and if there's still a problem, we can ask Let's Encrypt staff to take a look to try to identify the reason.

7

You’re using a cron job or timer that’s renewing right after 01:00 UTC on the first day of every month.

Did you set it up yourself? Does it specify custom options? Did you have a specific need to set it up that way?

This is speculation, but it might just be that Let’s Encrypt was overloaded for a few minutes and some requests failed.

The Certbot Debian package should have installed a cron job and/or systemd timer that runs twice a day, at completely random times, to ensure better load distribution. And, like I said before, the default behavior is to renew about every 60 days, not every month.

If you verify that the normal cron job/timer is active and everything is configured appropriately and disable this other one, you might not have any future problems.

8

Hi mnordhoff,

thanks for your answer.
i do not think, that the “normal” cron job renewed this time,
cause it was only renewed for 30 days, like my shedule says.

i will though look if there was a new cron job was installed with this update.

thanks for your input.

cheers mike.

9

hi schoen,

thanks for yor answer.
i also thought, it might be an overload.

i will try juergen’s tip.

cheers mike

10

hi juergen,

thanks for your answer.
i will modify the command to:
certbot renew --webroot certonly --force-renewal

will this work?

thanks for your assistance.

cheers mike

11

hi juergen again.

i tried your command;
certbot renew --webroot certonly --force-renewal

and get the output:

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: unrecognized arguments: certonly

cheers mike

12

Remove the certonly, I've read that wrong. That was a --dry-run command.

13

OK i used:

certbot renew --force-renewal

and got now the output:

Processing /etc/letsencrypt/renewal/mail.mididoc.com.conf

Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mail.mididoc.com
Waiting for verification…
Cleaning up challenges

new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/mail.mididoc.com/fullchain.pem

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/mail.mididoc.com/fullchain.pem (success)

strange though.

will have a look, if other shedule was installed with the update.
do you have a tip, where this could be?

cheers mike

14

hi again,

i found following entries in etc/letsencrypt/renewal/mail.mididoc.conf
which was not made by me.

renew_before_expiry = 30 days
version = 0.28.0
archive_dir = /etc/letsencrypt/archive/mail.mididoc.com
cert = /etc/letsencrypt/live/mail.mididoc.com/cert.pem
privkey = /etc/letsencrypt/live/mail.mididoc.com/privkey.pem
chain = /etc/letsencrypt/live/mail.mididoc.com/chain.pem
fullchain = /etc/letsencrypt/live/mail.mididoc.com/fullchain.pem

could this have caused the problem?
should i delete this?

as said my shedule is made by me and contents only the command:
certbot renew --force-renewal

thanks for advice.

cheers mike

15

You shouldn't use --force-renewal in a cron job.

That creates a new certificate, instead of checking if the certificate is "old enough".

Use

certbot renew
16

I know,
however,
the same command didn’t succeed this morning,
and succeded this evening.

also i did not find any other shedule than mine.

so i’m pretty sure, that it was a server problem beeing overloaded …

thanks for all the tips and very fast help, indeed.

have a nice evening.

cheers mike

17

cat /etc/cron.d/certbot or systemctl cat certbot.timer?

18

hi mnordhoff,

these commands confirm my result, that no other shedule exists.

thanks for your help.

cheers mike

19

FWIW, the provided cron job for Ubuntu is similar to:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root perl -e 'sleep int(rand(43200))' && certbot -q renew
20

thanks for the info.

cheers mike