Tried renewing our certs on a box today and seeing the following issuer:
CN=Fake LE Root X1
Any ideas what’s going on?
That means you issued those certificates against the staging server (possibly with --test-cert or --dry-run). You should reissue against the production server by removing those flags from your client invocation, if present.
1 Like
Thanks, I did indeed run the command once with –test-cert while trying to test renewals. However the letsencrypt-auto client aborted, saying the test-cert would overwrite my existing certs.
I’m wondering - on successful certificate generation does the letsencrypt-auto command preserve the flags used to generate the certificate and run them again on subsequent invocations?
The settings are stored in /etc/letsencrypt/renewal/*.conf. You can review or change them using any text editor. The relevant setting for staging vs. production would be the server line, for which the production value is:
server = https://acme-v01.api.letsencrypt.org/directory
1 Like
Thanks, explains that issue.
Is there any problem with sticking extra files in the live/example.com or archive/example.com folders?
For example the first time I ran LE I got a valid cert (this was before I messed about with the test-cert flag). To use the new LE cert it in my Jetty (Zimbra) application I needed to add the LE root CA to the bottom of chain.pem. I created a new file in the live/example.com folder called chain-ca.pem.
My Jetty application accepted the new chain-ca.pem and the private key perfectly. All worked great.
On attempting to renew though LE-auto created a folder suffixed with -0001. It complained about my renew/domain.conf file being corrupted.
I’m wondering if either:
- LE-auto doesn’t like extra files in live/domain or archive/domain
or
- My Java certificate command somehow messed up one of the symlinks in the live folder since inspecting it shows chain.pem no longer pointing to archive/example.com/chain.pem. It exists now as a file.
Trying to figure out the issue but I’ve hit the limit on number of times I can renew my cert (5 times per week right?) so don’t think I can troubleshoot until next week! 
I think extra files in /etc/letsencrypt/live should be fine. I wouldn't recommend doing anything in /etc/letsencrypt/archive, not sure how confused the client would get because of that.
As long as the symlinks are kept as-is, there shouldn't be any issues. I'm doing something similar in a custom renewal script for HAProxy, and it seems to work.
-0001 folders are usually created when you run letsencrypt with some domains you already have a certificate for, while adding additional subdomains. You can use --expand to avoid this (that one will replace the existing files). Not sure if the symlink issue could be another reason for this.
1 Like
Thanks will try again. Is the –test-cert step the only way to test LE generation and renewals without bumping against the renewal limits?
Yep.
For renewal with ./letsencrypt-auto renew, there’s also --dry-run, which will use the test server but won’t actually replace the certificates in /etc/letsencrypt/live/. It’s useful whenever you just want to make sure your configuration is going to work the next time your certificates are renewed.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.