Default renewal settings lead to "too many certificates already issued" #22

New Issue

Ghost · 2020-05-12T19:57:32Z

Ghost commented

2020-05-12 19:57:32 +00:00

I'm running into an issue with the 90 min renewal which results in recurring errors:

Error cert_renewal:
[acme-v2.js] authorizations were not fetched for 'my.domain.com':
{"type":"urn:ietf:params:acme:error:rateLimited","detail":
"Error creating new order :: too many certificates already issued for exact set of domains:\
my.domain.com: see https://letsencrypt.org/docs/rate-limits/","status":429,"_identifiers":
[{"type":"dns","value":"my.domain.com"}]}

When I used npx greenlock add --subject my.domain.com --altnames my.domain.com, the following was auto-populated in my greenlock.d/config.json:

"sites": [
  {
    "subject": "my.domain.com",
    "altnames": [
      "my.domain.comm"
    ],
    "renewAt": 1
  }
]

After some debudding, I noticed this check for renewAt in @root/greenlock/certificates.js:312:

C._renewableAt = function(gnlck, mconf, args, pems) {
    if (args.renewAt) {
        return args.renewAt;
    }

The problem is that renewAt is always 1. Even if I remove "renewAt": 1 line from config.json, greenlock still defaults to 1 and the manager overwrites the file to update it back to 1. As a result, this line @root/greenlock/certificates.js:61:

if (!C._isStale(gnlck, mconf, args, pems)) {

seems to always evaluate to false because of this comparison in C._isStale in @root/greenlock/certificates.js:263:

if (Date.now() >= renewAt) {
    return true;
}

So C._isStale always returns true, even if the cert is brand new! (On a side note, doesn't this render _renewOffset checks useless since the code is never reached?)

Is there any way to bypass this renewAt fuss? I'd much rather let C._renewableAt continue the flow and do the proper check against pems.expiresAt + renewOffset.

Thanks!

I'm running into an issue with the 90 min renewal which results in recurring errors: ```sh Error cert_renewal: [acme-v2.js] authorizations were not fetched for 'my.domain.com': {"type":"urn:ietf:params:acme:error:rateLimited","detail": "Error creating new order :: too many certificates already issued for exact set of domains:\ my.domain.com: see https://letsencrypt.org/docs/rate-limits/","status":429,"_identifiers": [{"type":"dns","value":"my.domain.com"}]} ``` When I used `npx greenlock add --subject my.domain.com --altnames my.domain.com`, the following was auto-populated in my `greenlock.d/config.json`: ```json "sites": [ { "subject": "my.domain.com", "altnames": [ "my.domain.comm" ], "renewAt": 1 } ] ``` After some debudding, I noticed this check for `renewAt` in `@root/greenlock/certificates.js:312`: ```js C._renewableAt = function(gnlck, mconf, args, pems) { if (args.renewAt) { return args.renewAt; } ``` The problem is that `renewAt` is **always** `1`. Even if I remove `"renewAt": 1` line from `config.json`, greenlock still defaults to `1` and the manager overwrites the file to update it back to `1`. As a result, this line `@root/greenlock/certificates.js:61`: ```js if (!C._isStale(gnlck, mconf, args, pems)) { ``` seems to always evaluate to `false` because of this comparison in `C._isStale` in `@root/greenlock/certificates.js:263`: ```js if (Date.now() >= renewAt) { return true; } ``` So `C._isStale` **always** returns `true`, even if the cert is brand new! (On a side note, doesn't this render `_renewOffset` checks useless since the code is never reached?) Is there any way to bypass this `renewAt` fuss? I'd much rather let `C._renewableAt` continue the flow and do the proper check against `pems.expiresAt + renewOffset`. Thanks!

coolaj86 commented

2020-05-12 21:28:10 +00:00

Do you happen to have greenlock.d/config.json on a read-only volume?

Or did you perhaps start the process as the root user and then change to a different user (i.e. www-data or httpd)?

I would suggest that you run:

sudo chown -R $(whoami):$(whoami) greenlock.d/

or perhaps:

sudo chown -R www-data:www-data greenlock.d/

The config.json file is not intended to be edited by hand and its permissions are kept secure, so if you accidentally run an npx command as root, it will lock the permissions to root.

Do you happen to have `greenlock.d/config.json` on a read-only volume? Or did you perhaps start the process as the `root` user and then change to a different user (i.e. `www-data` or `httpd`)? I would suggest that you run: ```bash sudo chown -R $(whoami):$(whoami) greenlock.d/ ``` or perhaps: ```bash sudo chown -R www-data:www-data greenlock.d/ ``` The `config.json` file is not intended to be edited by hand and its permissions are kept secure, so if you accidentally run an `npx` command as `root`, it will lock the permissions to `root`.

Ghost commented

2020-05-13 03:39:50 +00:00

Thanks for your quick reply. I'm running the app in Docker with greenlock-store-fs, and only the certs directory is mapped as a volume to the host. I suppose greenlock.d directory should also be a volume as well? Does Greenlock update renewAt in config.json after it orders a new cert?

Thanks for your quick reply. I'm running the app in Docker with `greenlock-store-fs`, and only the certs directory is mapped as a volume to the host. I suppose `greenlock.d` directory should also be a volume as well? Does Greenlock update `renewAt` in `config.json` after it orders a new cert?

coolaj86 commented

2020-05-13 03:52:07 +00:00

You're welcome. You just happened to catch me at a good time... twice.

Yep. Yep. Needs to be a writeable, persistent volume.

For most people I recommend using something simple and easy like Digital Ocean, Scaleway, or Vultr rather than complex tools like Docker that really require expert-level knowledge to use correctly - especially for small projects that don't need enterprise-level configuration, etc.

You're welcome. You just happened to catch me at a good time... twice. Yep. Yep. Needs to be a writeable, persistent volume. For most people I recommend using something simple and easy like Digital Ocean, Scaleway, or Vultr rather than complex tools like Docker that really require expert-level knowledge to use correctly - especially for small projects that don't need enterprise-level configuration, etc.

Ghost commented

2020-05-13 03:57:48 +00:00

Got it, adding greenlock.d as a volume then; will test again after they "unban" the domain. I guess this was an oversight on my part; that said, would be great to mention this in the readme (i.e. must have a volume for both the certs and the config if using Docker). Thanks so much for your help!

Got it, adding `greenlock.d` as a volume then; will test again after they "unban" the domain. I guess this was an oversight on my part; that said, would be great to mention this in the readme (i.e. must have a volume for both the certs and the config if using Docker). Thanks so much for your help!

👍 1

Ghost closed this issue

2020-05-13 03:58:03 +00:00

coolaj86 commented

2020-05-13 04:03:10 +00:00

I'm re-opening this just as a test to see if notifications come through with the new SMTP settings (which was why I was on just now).

coolaj86 reopened this issue

2020-05-13 04:03:10 +00:00

coolaj86 commented

2020-05-13 04:03:36 +00:00

closing again, hoping to see an email come through to myself with notification

coolaj86 closed this issue