"No renewals were attempted" and "no renewal failures"?

Help
1

I originally installed my certificates using the certbot standalone server because I was having issues with the webroot version working. The certificates are in /etc/letsencrypt/live/mydomain.tld and all of this is working well. However, I want to make sure it’ll renew properly when the time comes.

I run “certbot renew --dry-run” and the response is “No renewals attempted” with the log file stating “no renewal failures”. Looking at this and the logs it is unclear if this means it would have been successful had my certs been near expiry? Were no renewals attempted because it didn’t even try or it couldn’t find them? It doesn’t list my certs as part of the output.

My domain is:
[I don’t think I need to list it to resolve this issue]

I ran this command:
certbot renew
OR
certbot renew --dry-run

It produced this output:
“No renewals were attempted”

Log file includes:
“no renewal failures”

My operating system is (include version):
Jessie Lite

My web server is (include version):
nginx 1.10.1

My hosting provider, if applicable, is:
N/A

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

2

You could try adding the --force-renewal switch. This would force the renewal (duh :stuck_out_tongue:) and you could dry run it with --dry-run.

3

Hey @Osiris, thanks for the suggestion. I have tried the force option (and tried it again now). It gives the same response. I feel like it’s not working because an additional description in the output with the dry run says:

** (The test certificates below have not been saved.)
No renewals were attempted.

However, there are no certificates listed in the output…

4

Could you get a more verbose log and send us the client log from /var/log/letsencrypt? It sounds like somehow the renewer isn’t seeing that any of your certs exist!

5

The contents of the log haven’t been very helpful for me…see below

GNU nano 2.2.6 File: letsencrypt.log 2016-10-21 19:08:41,561:DEBUG:certbot.main:Root logging level set at 30
2016-10-21 19:08:41,564:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-10-21 19:08:41,567:DEBUG:certbot.main:certbot version: 0.8.1 2016-10-21 19:08:41,567:DEBUG:certbot.main:Arguments: [’–dry-run’]
2016-10-21 19:08:41,570:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#webroot,PluginEn$2016-10-21 19:08:41,572:DEBUG:certbot.renewal:no renewal failures

6

Could you also run with -v -v? I’m not sure if it will change anything, but you might see more information in the output.

7

Yes, basically the contents of the log file were printed in addition to the standard output. I agree that it seems like certbot doesn’t know about my certificates, but I just don’t know how to fix it. I’m tempted to uninstall certbot and letsencrypt and delete the certificates and try all over, but I feel that that shouldn’t be necessary.

8

Hmmm, I’m sorry about that! Can you tell me about what you have in /etc/letsencrypt/renewal? Have you changed any of those files at all?

9

That location does exist, but there are no files in that location at all (not even any hidden files or folders)

10

Hmmm, well, that’s definitely why it’s not attempting to renew anything!

I don’t know how you got certificates without associated files there. You said you have data in /etc/letsencrypt/live (and /etc/letsencrypt/archive)? Corresponding files in /etc/letsencrypt/renewal should have been created at the same time.

You don’t have any memory of deleting anything there or using any other tools or scripts that would have deleted or moved files there?

Do you have older log files from /var/log/letsencrypt at the time of the original issuance of the certificates?

11

I think the first time I was doing this I gave certbot a different location to place files, following some directions on some other website. After using the standalone version I remember manually moving the certificates to the usual (aforementioned) folder, but any other things that were created might not be located in the right place (I didn’t know files other than the certificates were placed anywhere). The location I originally extracted things to might be deleted.

There are several other log files in the log location, but it seems none correspond to the original issuance of the certificates.

If it would be best for me to kind of uninstall/purge and start over, I can do that :confounded:

12

@koreywithak, I think that does explain what you’re seeing, unfortunately. The other files apart form the certificates are used to keep track of what certificates need to be renewed and some information about how to renew them.

It’s possible to reconstruct these other files, but it will involve a fair amount of research, so if you think starting over is feasible, that would be the most straightforward path.

1 Like
13

Does this mean to scrap my current certificates as well as uninstalling certbot and letsencrypt?

14

I don’t think you’d need to reinstall – just scrapping your current certificates (presumably including server configuration references to them).

15

Okay I got everything going again, using standalone (I don’t know why I can’t get my server to serve the necessary files). I now do this:
certbot renew --dry-run
and I get this error:
2016-10-21 18:28:49,209:WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/mydomain.tld.conf produced an unexpected error: At least one of the (possibly) required ports is already taken… Skipping.
** 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/mydomain.tld/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)

I replaced my domain with mydomain.tld in all of this posting. The renewal works if I stop my webserver.
Is it trying to do the renewal using standalone because I got the original certificates using the standalone installer? I’d like to get the webroot version working so I don’t have to start/stop my server with those hooks. Do you see a problem with my nginx config file?
upstream php-handler {
server 127.0.0.1:9000;
#server unix:/var/run/php5-fpm.sock;
}

server {
listen 80;
server_name mydomain.tld;
# enforce https
return 301 https://$server_name$request_uri;
}

server {
listen 443 ssl;
server_name mydomain.tld;

ssl_certificate /etc/letsencrypt/live/mydomain.tld/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.tld/privkey.pem;

#Added for extra security
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-$
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;

# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains” al$
# preload;";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;

# Path to the root of your installation
root /var/www/;

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
# rewrite ^/.well-known/host-meta /nextcloud/public.php?service=host-meta
# last;
#rewrite ^/.well-known/host-meta.json
# /nextcloud/public.php?service=host-meta-json last;

location = /.well-known/carddav {
  return 301 $scheme://$host/nextcloud/remote.php/dav;
}
location = /.well-known/caldav {
  return 301 $scheme://$host/nextcloud/remote.php/dav;
}
location /.well-known/acme-challenge {
    allow all;
    root /etc/letsencrypt/live/mydomain.tld/;
}
location ^~ /nextcloud {

…

16

You shouldn’t make the live directory web-accessible. People can potentially download your system private key.

If you’re using the webroot method, just make sure set the alias to an empty directory that can be used for the purpose of serving the auth file and make sure to set the right real directory in your certbot command. Alternately, if you can serve the file from the real web root, you can just use that structure instead.

1 Like
17

Whoa. Yeah that was a stupid mistake. Thanks for noticing it, @motoko. I have since updated the location with the following. For some reason the force renewal with a dry run (with webroot option) says it succeeds even when I had stoped the nginx service. I don’t know how that can be possible unless it automatically starts the standalone server on a failure of the webroot or something. Anyways, I renewed the certificate with “certbot certonly” and forced a real renewal using my webroot and it says it succeeded (no standalone this time). The certificates definitely changed. It seems like it is all working and it scores well at https://www.ssllabs.com/ssltest/analyze.html. Thanks to you both for your help.

location ^~ /.well-known/acme-challenge/ {
    root /var/www/tmp/certbot;
}
location = /.well-known/acme-challenge/ {
    return 404;
}
18

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