New cert only valid for 2 weeks?

Yesterday I got an email reminder to update my certificate. I just did so, using a script I wrote which updates and then uses keytool to generate a JKS keystore in “keystore.new” ready for installing into my server. This is only the second time I’ve updated, so as a sanity check I had a look at the keystore using “keytool -list -v -keystore keystore.new” and this is what I see:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: 1
Creation date: Aug 31, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=sophotech.ddns.net
Issuer: CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US
Serial number: 3dead2adb98e454acfb6ebf56fd9a86445f
Valid from: Sun Jun 18 13:07:00 IDT 2017 until: Sat Sep 16 13:07:00 IDT 2017
Certificate fingerprints: [etc]

Can anyone tell me why the “Valid from” period is June 18th to Sept 16th rather than Aug 31st to somewhere in November?

It’s not a new cert. :sweat: All Let’s Encrypt certificates are valid for 90 days. That one was issued June 18.

I’m not sure (yet) whether a new certificate has been created, but if it has, it’s not being used by that tool.

1 Like

OK, I looked at my logfiles and discovered the problem – I had run “sudo certbot-auto -renew” which produced a gazillion error messages along these lines:

rm: cannot remove /home/user/.local/share/letsencrypt/lib/python2.7/foo.pyc
Permission denied

The ./local/share/letsencrypt directory is owned by root, but whichever subprocess certbot-auto spins off to upgrade its Python libraries is obviously no longer running as root.

I can see three possible solutions:

  1. Prevent certbot-auto trying to update its libraries – I noticed a --no-self-upgrade flag when looking inside certbot-auto to figure out what happened, but I tried it and it seemed to make no difference.
  2. Run a root shell, and run certbot-auto from this – this worked, all the Python libraries were updated, so I’ve now renewed successfully
  3. Change the ownership on .local/share/letsencrypt so that I can update it without being root – but I suspect that the new installation will once again end up being owned by root.

The only option that seems to work is (2), but I really don’t like running root shells – too much risk of accidents. Can anyone tell me if there’s anything I can do so that I can just use “sudo certbot-auto”?

sudo may be configured not to modify the HOME environment variable. So even though Certbot is running as root, when it tries to modify ~/.local, it’s your home directory.

You can use sudo -H or, as you said, open a real root shell. (Or modify sudo's configuration, but that sounds more dangerous.)

1 Like

Yes. ~/.local is mine, not root’s. There is no ~root/.local. All the certbot stuff is in my own .local, so sudo -H won’t help.

In any case, the fact that all is well in a root shell puzzles me. Why can a root shell modify my .local but sudo can’t? I haven’t looked at the details in certbot-auto, but it looks like the update is running as me, not as root, and I don’t understand why.

If you run "sudo -H certbot-auto", that should cause it to install a second copy of itself in ~root/.local.

The root shell should have HOME set to root's home directory.

No, I used "sudo bash" to avoid that happening, since everything was installed into ~user/.local (thanks to using "sudo" to install in the first place). So I'm running as root, with HOME set to ~user, with root as the owner of .local/share/letsencrypt and everything within it, and running "certbot-auto -renew" works. But running certbot auto directly as "sudo certbot-auto -renew" fails with "permission denied" errors, and I don't understand why this should be so, since once again I'm running as root, with HOME set to ~user, with root as the owner of .local/share/letsencrypt and everything within it.

Why should root be denied the right to delete its own files in one case and not in the other, unless for some reason I cease being root at some point inside "sudo certbot-auto"?

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