Error renewing certificate

#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