JFFS/.le/domain_name/domain.key <Never Updates (ASUS)

I am using an ASUS RT-AC68U and I originally made a succesful registration for DDNS via ASUSCOMM.COM and received a LE Cert. All worked great until renewal time. It renewed, gave the new date, but browsers still saw the old expiration of the cert and came up with the insecure warning. After trying multiple things, I SSH'd in (via a forum suggestion) and tried to rename and/or delete the domain.key file. Even after trying to delete the entire .le folder, the domain, key was re-created with today's date but the context within the file still contained the original key with the expiration of last month. So LE is sending me the same cert that expired yet the user dashboard for the ASUS router AND the file itself under the jffs/.le/domain/ folder show it's been updated. The data within the cert being updated is the same basically. Any suggestions? -Thanks

1 Like

LE never heard about leaf certificates private key so router never deleted the privkey: think your router is in read only state

3 Likes

Everything under the /jffs/.le/ folder was deleted manually. Then under /etc the "cert.crt", "cert.pem", & "key.pem" were not deleted manually but updated. Should I be looking in another folder or is this where you are referring to?

Did you restared the web server?

2 Likes

Yes.

service restart_httpd

Same issue persists unfortunately. Wondering if I should delete the three items listed above within the /etc folder next.

As a footnote: All the files under the jffs/.le folder have permissions set to 644 and the domain.key file is set to 600. The domain.conf file is showing the correct creation and renewal time but externally, this is coming up with the old expiration date still so yielding unsecured HTTPS access.

Now I can no longer test. Due to multiple attempts trying to fix this, I now get the:

too many certificates (5) already issued for this exact set of domains in the
last 168 hours

How do I reset that?

You wait.

In the future, you will benefit from using the staging endpoint when testing. It does not issue valid certificates, but it has much more generous rate limits.

4 Likes

Well that's good to know now for future testing. As for the wait time, how long is that? Mins, hours, days, etc.?

Thanks!

1 Like

Seven days from your oldest, duplicate (same SANs) certificate.

See:

5 Likes

The full error message shows a date/time the next attempt might succeed.

It is possible Asus client removes that part of the message.

4 Likes

Hi @Preroll,

That isn’t exactly true.

You still do testing and debugging using the Staging Environment as the Rate Limits are much higher.

3 Likes

Seven days from the the oldest cert? I need to get this up and running this weekend. Ok, I guess I'll have to use another cert publisher and start over. Thanks for the input.

1 Like

Hi @Preroll,

To assist in your search for other Free ACME Certificate Authorities here are a couple of resources

4 Likes

You must have been issued fewer than 5 production certificates for a given set of SANs in the last 7 days in order to be issued another production certificate for the same set of SANs.

So, technically, your 5th-newest certificate for a given set of SANs must be at least 7 days old.

3 Likes

This is the list, So what date am I looking to renew again at?

image

If those certs all cover the exact same set of SANs, you're looking at sometime on 7/17 GMT. There's a lot of information missing here for me to evaluate properly, like the domain name(s).

4 Likes

Count down to the fifth cert and add seven days to that date.

4 Likes