Closed nwesoccer closed 6 years ago
Yes, sorry. It's been on my todo list to add this functionality. I'll get to that this coming weekend. Thanks for letting me know!
hey @nwesoccer ... just pushed b1d4966 which I think can help you get a wildcarded certificate. All you should need to do is change the URL as in the readme update, and put a wildcarded domain in the cert info. Let me know if it works! Been working on it all morning and going to take a break lol. Later on I'll make sure it works in all the different cases that the v1 used to.
@larryboymi Awesome! Thanks for the work. I am running into a issue when running npm run local-cert
, but not sure if it's related or not.
const defaultCertInfo = {
'site1': ['*.site1.example.com'],
'site2': ['*.site2.example.com']
}
The first certificate seems to fail with the following error, while the second seems to succeed:
[ { err: true, msg: 'Updating cert for site1, received err Error: Bad Request, Error: Bad Request\n at Request.callback (/Git/node-letsencrypt-lambda/node_modules/superagent/lib/node/index.js:696:15)\n at parser (/node-letsencrypt-lambda/node_modules/superagent/lib/node/index.js:906:18)\n at IncomingMessage.res.on.e (/node-letsencrypt-lambda/node_modules/superagent/lib/node/parsers/json.js:19:7)\n at emitNone (events.js:91:20)\n at IncomingMessage.emit (events.js:185:7)\n at endReadableNT (_stream_readable.js:926:12)\n at _combinedTickCallback (internal/process/next_tick.js:74:11)\n at process._tickDomainCallback (internal/process/next_tick.js:122:9)' }, { ETag: '"xxx"', ServerSideEncryption: 'AES256' } ]
I'm assuming you changed your url for v2. There's a chance you might need to delete your account registration json and allow it to be recreated, but I thought they were backwards compatible. Like I said.. just got it initially working with a single wildcard domain earlier. I'll be building in some resiliency soon (and allowing N certs at a time). Haven't tested all of that yet.
Yes that is correct. I've debugged a little more. Actual error from letsencrypt is:
url: 'https://acme-staging-v02.api.letsencrypt.org/acme/finalize/######/######',
method: null,
statusCode: 400,
statusMessage: 'Bad Request',
client: [Object],
_consuming: true,
_dumped: false,
req: [Object],
text: '{\n "type": "urn:ietf:params:acme:error:malformed",\n "detail": "Order\'s status (\\"invalid\\") was not pending",\n "status": 400\n}',
Every once in a while it works fine, so like you said, it may just be some resiliency. It's also possible I'm just in a bad state with letsencrypt and waiting a few hours/day will clean some stuff up.
Maybe there was an error while validating... I'll be improving the codebase this week. I'll let you know
Improved some of the error messaging in 97849c6 (along with subdomains and wildcarded subdomains), and ran into a case where I received internal server errors from LE server. I added to this forum post.
However in the lambda I think it will need to be retried, since the error sort of forces the challenge verifications to occur again and that's not a great side effect, almost built in and tried retry logic, except since it enters an invalid state for the order, it makes me need to backtrack too much (could be coded, but once they fix the internal error, it'd render a lot of code useless).
If this stays an issue for too long I may put in the retry/re-verify challenge logic.
If I request a certificate for ["mydomain.com", "*.mydomain.com"]
, it appears to attempt to set two DNS challenges to the same key (_acme-challenge.mydomain.com
) simultaneously, so one overwrites the other and challenge validation fails. Is this a configuration that is expected to work?
I'll have to add that case. I do know that acme doesn't like a redundant fqdn/subdomain combo...but haven't specifically coded your case.
Great, thanks! Looks like they call out this case as explicitly supported:
Orders that contain both a base domain and its wildcard equivalent (e.g. .example.com and example.com) are valid. In that case, there will be two authorization objects in the order for “example.com”, one of which represents the wildcard validation and one of which represents the base domain validation. Redundant entries will produce an error. For instance, an order containing both .example.com and www.example.com would produce an error since the wildcard entry makes the latter redundant.
I think all that is needed for that case is to add a 2nd TXT record for the DNS-01
challenge (when they collide)... should be able to code that in soon. Trying to improve the codebase, esp now that lambda supports node 8.10.
Locally I just hacked it to run all DNS challenges serially instead of in parallel, which works, but I figured that this is a terrible approach since most of them can be run in parallel.
@thenickdude, I added 32c4495 in which I believe I've supported it correctly. Let me know how it goes! Thanks..
I'm not sure if I doing something wrong. When I run npm run local-cert
I get the error Couldn't write token digest to DNS record. Error: Could not pre-validate DNS TXT record. Didn't find xxxx for yyyy
.
Hard to tell without seeing your config. I did move the codebase to 8.10 but haven't implemented any/many new features yet. I tried emailing you @nwesoccer the other day but not sure if it went thru.
@larryboymi Sorry about that, don't often check the email. I have responded to the email. It's also possible I'm on an older version of node. So I can update and try that.
@nwesoccer I think we resolved your specific case over email. If it's ok with you I'll close this issue now (unless a lot of ppl experience Internal Server Errors against letsencrypt).
Sounds good. Thanks again for all the work!
Thanks, the new version works great for me now!
Glad to hear it!
These scripts fail when using the new ACME v2 to provision certificates. We are trying to use lambda to provision some wildcard certs. https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578