[Solved] My certificate became invalid twice for an unknown reason

I am using Let’s Encrypt certificate for my domain trespasser.eu.org since January 2017 an everything has been fine until now. On August 10 the certificate became invalid and was replaced with Comodo one by my hosting provider via AutoSSL feature.

I contacted their support. You may read the discussion here:

When I tried to re-download my certificate via Java (porunov) acme-client an “Can not download certificates. Either you haven’t generated one or they already expired.” error was returned. However, I renewed Let’s Encrypt certificate and installed it back without any issue.

But today the same incident happened again.

  1. How can I figure out why my certificate became invalid twice?
  2. Are there any detailed logs available? (via REST API or any other)
  3. Is there an email support or any other way to contact Let’s Encrypt specialists directly?

Certificates are valid for 90 days from issuance. You will need to use your ACME client to renew it before that happens. This can typically be automated using a cronjob. The recommended renewal schedule is 30 days before expiration (i.e. every 60 days) - that leaves a month for you to intervene if something goes wrong. How renewal works depends entirely on your client. You can find the renewal documentation for your client here. This is different from the process of re-downloading your existing certificate (which would just get you the expired certificate again).

Note that this is only the first step - you will also need to replace the certificate and key on your web server the same way you installed it initially, otherwise cPanel will presumably replace it again.

Let's Encrypt offers community support through this forum. Other support channels are not viable given Let's Encrypt's issuance volume and user count.

Two more things to note that aren't really an answer to your questions, but might be relevant:

  • cPanel/AutoSSL supports Let's Encrypt natively, meaning it would manage all this for you. I believe your web host would have to explicitly enable Let's Encrypt on their end. It's worth asking them whether they can do this. (I'm not certain if enabling two CAs at the same time works.)
  • If the Comodo-issued certificate from AutoSSL worked for you, and you don't have any particular reason for wanting to stick to Let's Encrypt-issued certificates, the Comodo certificate might be good enough. It's probably not worth the effort if cPanel provides a managed solution. Generally speaking (and, yes, oversimplifying a bit), the choice of CA doesn't matter all that much, and most major CAs are "good enough". There's no lock-in, so even if something happens to Comodo, you can always go back to Let's Encrypt or any other trusted CA. That said, if your web host can enable Let's Encrypt as an option in AutoSSL, go for that. :smile:

My certificate was valid until October 2017. When I renewed it after the first replacement incident it was valid until November 10, 2017.

But now acme-client returns an error I’ve posted above. Maybe it’s a bug and acme-client works incorrectly. Unfortunately I did not save the certificate files on my local PC. I will check it the next time.

More likely my certificate really became invalid due to instable AutoSSL feature on my hosting. Or there was some other reason that made the certificate invalid.

Let’s Encrypt API does not provide enough info about the reasons why certificate became invalid. There were no email notifications from Let’s Encrypt either.
But there were email notifications in March and June when I had to update the certificate due to 90 days expire. And I updated it that time without any issues.

So my main goal is to find the reason why the certificate became invalid now and prevent such incidents in future.

Did you replace/update the certificate on your web server after renewing using the ACME client? Skipping this step would have meant that cPanel saw the expired certificate and then proceeded to replace it. Note that this would not be the reason you got that error message from your ACME client, as AutoSSL would have only replaced the certificate on your web server, but wouldn't have touched the files stored by your client. More on that below.

Looking at the source code of your ACME client, the error means that no non-expired certificate was found locally, in the location the client is configured to look for certificates (presumably the work- and cert directory). This is a local operation and does not touch Let's Encrypt's API.

This is either a bug in the client or an issue with how it's used. For example, if you used -w /foo or --cert-dir /bar when you first obtained the certificate, but skipped this when renewing or redownloading (or vice-versa), the client would not look in the location you originally stored the certificates in, and it would seem that you either don't have any certificates locally, or only expired ones. Without knowing the exact sequence of commands you ran these last couple of months, it's hard to say what happened precisely.

Your renewed certificates (the one that expire in October and November) are still valid, your client and web server simply don't know about them. Assuming you're not dealing with a client bug, they should be in whatever directory you used for --cert-dir when you renewed them.

Yes. It has been installed correctly and everything was okay until today. When I found it replaced with Comodo once again.

This error occurs while executing download-certificate command. According to specification: https://github.com/porunov/acme_client/wiki/Command-reference
It should “Download previously generated certificates.” What purpose would this command have if the certificates are already stored locally? As I understand, it should just re-download my latest certificate files without actually renewing them.

There is a typo in the documentation, however. The command is not “download-certificates”, but “download-certificate”.

I suspect so, but I’m not sure.

When I run:

java -jar acme_client.jar --command download-certificate --newest-only -a /Documents/SSL/keypairs/AccountPrivate.key -w /Documents/SSL/workdir/ --cert-dir /Documents/SSL/cert/ --log-dir /Documents/SSL/logs/

I get an error in the log file:

ERROR com.jblur.acme_client.command.certificate.DownloadCertificatesCommand:27 - Can not download certificates. Either you haven’t generated one or they already expired.

When I run:

java -jar acme_client.jar -a /Documents/SSL/keypairs/AccountPrivate.key -w /Documents/SSL/workdir/ --command renew-certificate --cert-dir /Documents/SSL/cert/ --csr /Documents/SSL/csr/Domains.csr --log-dir /Documents/SSL/logs/

I get renewed certificate files in the /Documents/SSL/cert/ directory and no errors.

The renewed certificate is valid until AutoSSL replaces it with Comodo one. I have not checked if it is valid after the replacement because I don’t have the certificate files stored locally. And they are already overwritten with Comodo at server back-end. I can not download certificate files again because of an error, I can only renew them.

The only solution I see is to walk through the whole process once again, but save downloaded files and check if they are still valid after AutoSSL replaces them one more time. Or my hosting admins will turn off AutoSSL first.

How do you know it? How can I check if these certificates are valid or not?

The download-certificate uses this function to get all valid certificates. As you can see, it uses a local file (CERTIFICATE_FILE_PATH, which is located somewhere in your work directory) as its source for the list of certificates.

There's another way to know that this is a local operation: ACME simply does not have an endpoint that would return a list of all your certificates, so there isn't really any other way for the client to implement this. Managing existing certificates is more or less up to the client and not in scope for ACME (this is oversimplifying matters a bit, but correct in this context).

Are you saying that the actual files in /Documents/SSL/workdir/ were overwritten with a Comodo-issued certificate, or is this simply an assumption based on the fact that your server started using a different certificate? Overwriting these files would be a very weird thing to do for AutoSSL, I would encourage you to verify this by inspecting the certificate files.

"valid" can mean many things in the Web PKI, but typically it's defined as "non-expired" and "not revoked". By this definition, both the certificate issued on 2017-07-05 and on 2017-08-12 are still valid. The expiration date cannot be changed after the certificate was issued, and the revocation status is "GOOD" for both of them. You can see and download both certificates from crt.sh (this is a third-party site based on Certificate Transparency log servers) and paste the certificate content here to verify the OCSP status (or use the openssl command-line, but that way madness lies).

I see. My certificate_uri_list file was from April backup, therefore it is not related to certificate files renewed in July. That’s why acme-client returns an error.

I am using acme-client on my local PC and store the whole file structure in a password-protected archive. However I did not update this backup after I renewed my certificate in July.

AutoSSL overwrites the certificate on hosting only. Their support answered that AutoSSL should not overwrite valid (“non-expired” and “not revoked”) certificates. But they also mentioned some problems with AutoSSL and recent testing.

I have already posted the link to my hosting support forum where the issue has been discussed.

Thank you. That is what I exactly wanted to know.

So my certificates are valid and acme-client works correctly. It’s looking like an AutoSSL problem on my hosting then.

There was indeed a problem with AutoSSL feature. It’s turned off for my account now.

I restored my Let’s Encrypt certificate and everything seems to be fine.

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