Cannot renew certificate

Hi,

My domain is: git.thebluemountain.eu

I ran this command:
sudo certbot renew --apache --dry-run

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/git.thebluemountain.eu.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for git.thebluemountain.eu
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (git.thebluemountain.eu) from /etc/letsencrypt/renewal/git.thebluemountain.eu.conf produced an unexpected error: Failed authorization procedure. git.thebluemountain.eu (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://git.thebluemountain.eu/gitklub.well-known/acme-challenge/cG2Q2K3c9ZH44w0_tCUdUjryhUJxOh_Ljo4ofMgXT20 [37.187.238.35]: “\n\n404 Not Found\n\n

Not Found

\n<p”. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/git.thebluemountain.eu/fullchain.pem (failure)

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

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/git.thebluemountain.eu/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

My web server is (include version):
apache 2

sudo apache2 -v
Server version: Apache/2.4.25 (Debian)
Server built: 2018-11-03T18:46:19

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

cat /etc/debian_version
9.8

My hosting provider, if applicable, is:
ovh

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): no

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

  • I had been trying to renew the certificate for about a month, unsuccessfully.

  • apache server used to be opened on 443 port only.
    I have opened the apache server to port 80 to redirect to port 443

    ServerName git.thebluemountain.eu
    ServerSignature Off

RewriteEngine On
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

ErrorLog /var/log/apache2/redirect.error.log
LogLevel warn

I now have less than a month for the validity of the certificate and i have no idea of what to do.

any help would be greatly appreciated as i’m kind of stuck now.

Hi @thebluemountain

that looks good. Now use it with the correct command:

certbot run -a webroot -i apache -w /var/www -d git.thebluemountain.eu

Not with --apache as authenticator.

Juergen,

Thank you very much for your prompt reply.

This is what i now get:

sudo certbot run -a webroot -i apache -w /var/www -d git.thebluemountain.eu
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer apache
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for git.thebluemountain.eu
Using the webroot path /var/www for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. git.thebluemountain.eu (http-01): urn:ietf:params:acme:error:caa :: CAA record for git.thebluemountain.eu prevents issuance

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: git.thebluemountain.eu
    Type: None
    Detail: CAA record for git.thebluemountain.eu prevents issuance

… but i thought this was not required …

also, (not sure whether it helps), the running the command
sudo certbot renew --dry-run -a webroot -i apache -w /var/www … now generate the same error message about CAA record.

I have been looking at CAA record and I’m pretty much sure I don’t understand what i’m supposed to do yet.

Q1: do you confirm the CAA record is the problem?
Q2: do you know where should I look to get better understanding of what to fill for the expected ```

for the expected flags, tag, value ?

That’s good.

Checked your domain via https://check-your-website.server-daten.de/?q=git.thebluemountain.eu - there you see the error:

CAA - Entries

Domainname flag Name Value ∑ Queries ∑ Timeout
git.thebluemountain.eu 5 issue letsencrypt.org. 1 0
thebluemountain.eu 0 no CAA entry found 1 0
eu 0 no CAA entry found 1 0

Only letsencrypt.org. is allowed to create a certificate, not letsencrypt.org

:wink:

I see, I should add a warning message.

Hi Juergen,

Not sure I understand…
Would just turning the error into a warning on your side solve the ussue ?
… or is there something else i must do?

Letsencrypt.org uses

letsencrypt.org

as valid name. So if you allow only

letsencrypt.org.

then letsencrypt.org isn’t allowed to create a certificate.

Hi Juergen,

I guess I don’t remember about ‘allowing’ letsencrypt to create a certificate.
Would you have any pointer for me regarding where / which configuration on my side is wrong?

Sorry Juergen,

I think I understood.
I made a CAA record at my domain provider (gandi) … and it was stating for the value to enter (called ‘Hostname’ in their UI) …
“Warning: A hostname entry usually ends with a dot (.) unless you specifically want it to be suffixed by the current domain.”
I have updated and will wait for the record to be updated.

Once done, I will keep you updated.
Thank you very much for your precious help, Juergen,

Hi Juergen,

OK, I was able to run the command successfully:
sudo certbot renew --dry-run -a webroot -i apache -w /var/www

… but the command
sudo certbot renew --dry-run still fails with previous error

My understanding is that running the command: certbot run -a webroot -i apache -w /var/www -d git.thebluemountain.eu should succeed.

However, there is a service (systemctl start certbot.service) that is configured to run the command: /usr/bin/certbot -q renew … which fails.

Q: do you advise me to disable the service?
… or change the command associated?
… or make the command work as expected?
(i guess by changing / fixing the apache configuration)

That’s correct, please use this command and create a new productive certificate.

That changes the configuration file - so certbot renew will use the same parameters and will work.

But if you use only --dry-run, your config isn’t changed. So you see the wrong result.

1 Like

Hi Juergen,

I have been able to generate a new certificate with the command you supplied and the https site now provides the new certificate.

The certbot.service still display error upon starting …

certbot.service - Certbot
   Loaded: loaded (/lib/systemd/system/certbot.service; static; vendor preset: enabled)
   Active: inactive (dead) since Mon 2019-03-11 23:04:52 CET; 2s ago
     Docs: file:///usr/share/doc/python-certbot-doc/html/index.html
           https://letsencrypt.readthedocs.io/en/latest/
  Process: 27821 ExecStart=/usr/bin/certbot -q renew (code=exited, status=0/SUCCESS)
 Main PID: 27821 (code=exited, status=0/SUCCESS)

Mar 11 23:04:51 vps63854.ovh.net systemd[1]: certbot.service: Failed to set invocation ID on control group /system.slice/certbot.service, ignoring: Operation not permitted
Mar 11 23:04:51 vps63854.ovh.net systemd[1]: Starting Certbot...
Mar 11 23:04:52 vps63854.ovh.net systemd[1]: Started Certbot.

… but i guess this is a different issue that might rather refer to integration of cgroups with linux kernel.

I therefore have no longer any issue with certbot and will close the case.

I just wanted to express my gratitude for your very prompt and effective help at sorting the issue out.
Best regards,

It might be helpful to let Gandi know that this advice, while totally correct and important for things like A records, is misleading and confusing for CAA records in particular.

Hi Schoen,

I’ve let them know that this warning message might be inappropriate for CAA record.

1 Like

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