Renew not working for expired certificate

Help
1

My certificate has expired and the renew process doesn’t seem to work. It just says it updated the fullchain file?

My domain is: crawl.project357.org

I ran this command: letsencrypt-auto renew

It produced this output:

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/crawl.project357.org.conf
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/crawl.project357.org/fullchain.pem
-------------------------------------------------------------------------------

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/crawl.project357.org/fullchain.pem (success)

Checking that file:

# openssl x509 -in /etc/letsencrypt/live/crawl.project357.org/fullchain.pem -text -noout | grep -A2 Validity
        Validity
            Not Before: Apr 14 22:59:00 2016 GMT
            Not After : Jul 13 22:59:00 2016 GMT

My operating system is (include version): Ubuntu 14.04

My web server is (include version): nginx 1.8.1

My hosting provider, if applicable, is: AWS

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

What’s the output of ls -l /etc/letsencrypt/live/crawl.project357.org and ls -l /etc/letsencrypt/archive/crawl.project357.org? Curious if the symlinks got broken somehow.

1 Like
3 

# ls -l /etc/letsencrypt/live/crawl.project357.org
total 0
lrwxrwxrwx 1 root root 49 Jul 14 01:41 cert.pem -> ../../archive/crawl.project357.org-0001/cert1.pem
lrwxrwxrwx 1 root root 50 Jul 14 01:41 chain.pem -> ../../archive/crawl.project357.org-0001/chain1.pem
lrwxrwxrwx 1 root root 54 Jul 14 01:41 fullchain.pem -> ../../archive/crawl.project357.org-0001/fullchain1.pem
lrwxrwxrwx 1 root root 52 Jul 14 01:41 privkey.pem -> ../../archive/crawl.project357.org-0001/privkey1.pem

# ls -l /etc/letsencrypt/archive/crawl.project357.org
total 32
-rw-r--r-- 1 root root 1834 Apr 14 23:51 cert1.pem
-rw-r--r-- 1 root root 1809 Jul 14 01:41 cert2.pem
-rw-r--r-- 1 root root 1675 Apr 14 23:51 chain1.pem
-rw-r--r-- 1 root root 1647 Jul 14 01:41 chain2.pem
-rw-r--r-- 1 root root 3509 Apr 14 23:51 fullchain1.pem
-rw-r--r-- 1 root root 3456 Jul 14 01:41 fullchain2.pem
-rw-r--r-- 1 root root 1704 Apr 14 23:51 privkey1.pem
-rw-r--r-- 1 root root 1704 Jul 14 01:41 privkey2.pem

# openssl x509 -in /etc/letsencrypt/archive/crawl.project357.org/cert2.pem -text -noout | grep -A2 Validity
        Validity
            Not Before: Jul 14 00:41:00 2016 GMT
            Not After : Oct 12 00:41:00 2016 GMT

Aha! I think I know why this happened, I first tried to run letsencrypt renew by hand, without sudo. I guess it managed to create the certificates but not update these symlinks?

I updated the symlinks to point to the ‘2’ versions of these files and everything works as expected. Thanks!

PS, do I need to/should I manually clean up the ‘1’ versions?

1 Like
4

Hmm, good theory! I'll have to try to reproduce this, that would be rather annoying behaviour and should trigger some user-visible error instead of quietly proceeding.

No, that's fine. The client keeps all the old files in archive/ permanently. Deleting them might actually throw the client off and cause other issues during renewal.

1 Like
5

It may have generated a user-visible error. Unfortunately I don’t have the output any more. Certainly the part of my wrapper script which attempted to restart nginx would have failed.

I think perhaps letsencrypt renew should update symlinks if they weren’t pointing to the latest version of these files. I’ll file a github bug referencing this thread.

EDIT: https://github.com/certbot/certbot/issues/3288

6

Situations that can cause issuance (adding to the CT logs and to the per-FQDN-set counter) without the end user getting their certificate (can't write to file) are worth trying to prevent up front.

Normally it is bad practice to check file-write access (e.g. using the Unix access system call) because what your code needs to do is open, and if that fails report the error, so the access check performed earlier was redundant. But for certbot it makes sense to check very early, because then we can abort and tell the user we wouldn't have succeeded but without wasting their certificate issuances. If the user runs certbot, then swaps the permissions while it is running we'd still fail to write later on, but then the user got no more than they deserved, whereas if they forgot 'sudo' or they got the permissions set wrong somehow, or their disk went read-only due to a transient error, we should error out early IMNSHO.

7

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