Unable to renew a certificate


#1

I’m trying to renew a certificate for my site, https://www.japanizer.org. Validity period for the current certificate is:

Issued On Tuesday, July 5, 2016 at 1:37:00 PM
Expires On Monday, October 3, 2016 at 1:37:00 PM

Unfortunately it fails with:

# letsencrypt renew --agree-tos
(...some other domains valid for long...)
Processing /etc/letsencrypt/renewal/japanizer.org.conf
2016-09-22 05:00:17,202:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/japanizer.org.conf produced an unexpected error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains: japanizer.org,www.japanizer.org. Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/japanizer.org-0001/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

Why does it say that it issued too many certificates for japanizer.org,www.japanizer.org when the cert was last issued more than 2 months ago, on July 5, 2016?

Perhaps my “renewal” process is wrong?

I’m running this command daily via cron to trigger the renewal:

letsencrypt renew --agree-tos


#2

Looking at the certificates logged in Certificate Transparency log servers, it appears that you’re attempting to renew that certificate hourly (the “Not Before” date is 06:39:00, 07:39:00, etc.)

I would recommend reviewing your log files in /var/log/letsencrypt to see if the cronjob is triggering any errors (other than the rate limiting error).

If your log files don’t go that far back (the last successful issuance was on September 17th, around 8:39 am UTC), I would suggest you disable the cronjob for now and attempt to renew manually when the rate limits reset (on September 24th, right around the time the first certificate was issued on September 17th) to check if that causes any errors. Once that error is fixed, you can re-enable the cronjob.


#3

Indeed, my bad, I was attempting the renewal every hour, where it should be daily; corrected.

Still, I don’t understand why it is failing:

  • last issued certificate for that domain was more than 2 months ago

  • if the certificate was not yet close to renewal date - letsencrypt should just say so, and skip the renewal process (it does say so for other domains):

    The following certs are not due for renewal yet:
    /etc/letsencrypt/live/otherdomain.org/fullchain.pem (skipped)

So this error message is either wrong, or inaccurate:

Error creating new cert :: Too many certificates already issued for exact set of domains: japanizer.org,www.japanizer.org. Skipping.

Because the last issued cert for this domain was more than 2 months ago, it could mean that someone else obtained the cert for the very same domain? Confusing.

Anyway, hope correcting the cronjob will get it fixed.


#4

What command are you using in your cron ? it should only be renewing it if needed - not every time it get’s called.


#5

What command are you using in your cron ?

I’m using:

letsencrypt renew --agree-tos

it should only be renewing it if needed - not every time it get’s called.

That’s contradicting certbot docs:

Automating renewal

(…)

if you’re setting up a cron or systemd job, we recommend running it twice per day (it won’t do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let’s Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.


#6

Small, but important correction: the last certificate that your client successfully stored is from two months ago. It seems like your client is able to get Let’s Encrypt to issue the certificates, but somehow the client is unable to store them and therefore requests a new one whenever the cronjob is executed. That’s why I was curious about the logs from your last successful issuance (see date in previous post), those might show what went wrong.

Changing the cronjob to daily won’t fix this issue; you’ll need to figure out what the error is (which you can’t do until you either get the logs from your last successful issuance or wait for the rate limit to expire), fix that error, and then re-enable the cronjob.


#7

Unfortunately it still didn’t renew, and it expires in ~2 days. Renewing once a day only.

The error is as before:

# letsencrypt renew --agree-tos
Processing /etc/letsencrypt/renewal/japanizer.org.conf
2016-10-01 04:56:49,713:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/japanizer.org.conf produced an unexpected error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains: japanizer.org,www.japanizer.org. Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/japanizer.org-0001/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

Logs from the last successful issuance - I no longer have them. Letsencrypt only seems to store the logs for the past 10 days or so.


#8

crt.sh shows multiple certificates issued in the past few days. Did you disable the cronjob as recommended in my previous posts in order to debug this problem? If you did, it looks like there’s another cronjob somewhere on your end.

Please disable all cronjobs and try to renew manually (using the same command) once your rate limit resets, and then post the error you’re getting (not the rate limit error). With some luck, the error is also triggered if you use the staging environment (which has separate rate limits), so you could try letsencrypt renew --agree-tos --dry-run before that and see if that gives you any errors to work with.

You’ll be able to bypass the rate limit for duplicate certificates by adding another subdomain in case the rate limit doesn’t reset in time (I think you should be able to try again tomorrow, though).


#9

There is only this one single cronjob running, once a day.

Even if there was some other cronjob running on some different server (and it’s not - there is just a single server for this domain) - it shouldn’t succeed, as there is just one IP for japanizer.org / www.japanizer.org. So technically, Letsencrypt shouldn’t issue any other cert if there was someone else in the internet trying to issue the cert for a domain he/she doesn’t own, right?

There is also no staging or any other environment - this is a basic Wordpress website which barely ever changes.

Running with --dry-run doesn’t give any hints.

But - looking at the logs from the past day or so indeed shows that the cert was issued.

So I’ve looked into /etc/letsencrypt/ directory and discovered that there were several japanizer.org domains there:

/etc/letsencrypt/archive/japanizer.org
/etc/letsencrypt/archive/japanizer.org-0001

/etc/letsencrypt/live/japanizer.org
/etc/letsencrypt/live/japanizer.org-0001

So it seems letsencrypt was renewing the cert for “japanizer.org-0001”, while the webserver was using the config for “japanizer.org”. I’ve removed the japanizer.org-0001 and it finally renewed properly.

I don’t know why there was a domain “japanizer.org-0001” there, seems like an issue when initially creating the first certificate for this domain.


#10

-0001 directories are created when you request a certificate for a new subdomain in addition to domains you’ve already requested a certificate for, e.g. if you initially get a certificate for japanizer.org, and then add www.japanizer.org. This can be avoided by adding the --expand flag.

I’m curious whether the client will continue to request a new certificate daily, or if it’ll wait 60 days now as intended. Not sure why that’s happening, even with the -0001 directory.


#11

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