mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
ACME v2 Support #243
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lbelkind on GitHub (Aug 9, 2017).
In January 2018 Lets Encrypt will launch a new ACME v2 Endpoint that will allow wildcard certificates.
Any plans to implement this?
@GeorgeRT commented on GitHub (Oct 13, 2017):
Is your mic on?
@lukas2511 commented on GitHub (Dec 14, 2017):
Yes! I have a few use cases for wildcard certificates too, so this will definitively get implemented!
@lbelkind commented on GitHub (Dec 14, 2017):
Great news!
Do you have any timeline?
Is there any way we can collaborate / help you in this effort?
Leonid Belkind, Co-Founder & CTO, Luminate Security
Mobile: +972-52-3476783
leonid@luminatesec.commailto:leonid@luminatesec.com
[id:image001.png@01D3677E.939CE6B0]
This message may contain confidential and/or proprietary information, and is intended only for the person / entity to whom it was originally addressed.The content of this message may contain private views and opinions which do not constitute a formal disclosure or commitment unless specifically stated.
From: Lukas Schauer notifications@github.com
Reply-To: lukas2511/dehydrated reply@reply.github.com
Date: Thursday, 14 December 2017 at 1:30
To: lukas2511/dehydrated dehydrated@noreply.github.com
Cc: Leonid Belkind leonid@luminatesec.com, Author author@noreply.github.com
Subject: Re: [lukas2511/dehydrated] ACME v2 Support (#420)
Yes! I have a few use cases for wildcard certificates too, so this will definitively get implemented!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/lukas2511/dehydrated/issues/420#issuecomment-351558980, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXVzSfParsPJJ9oBTpPq0yXIfcqGPj-dks5tAF4igaJpZM4OyNHQ.
@lukas2511 commented on GitHub (Dec 15, 2017):
I haven't actually read the spec yet... If not too much has changed this may be implemented in January, certainly only pushed to master after the new endpoint is online. If it's more time consuming I'm guessing late Feb or Mar.
Certificate handling probably doesn't need to be touched a lot, support for wildcard certificates should be easily handled (script-internally) as if they would just be a normal subdomain, I'm kinda hoping that only a few api calls have to be changed.
A great help would be a short summary (if in any way possible...) of the major changes in the protocol.
If a lot has changed a proof of concept shell or python (or some other easily readable language) script with api calls against the new version would be great. Just something that gives a good starting point for figuring out how stuff works, nothing more.
@lbelkind commented on GitHub (Dec 17, 2017):
Can’t say that I am familiar with the current Boulder implementation of ACME enough to comment on the diff.
I am looking at the latest IETF-standardized ACME implementation (which, according to the ITRG people will serve as the basis for their ACME V2 Endpoint): https://tools.ietf.org/html/draft-ietf-acme-acme-07 [this is, at least, the latest available draft]
I am looking at the RFC diff: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-acme-acme-01.txt&url2=https://tools.ietf.org/id/draft-ietf-acme-acme-07.txt
The protocol was enriched significantly, the question is, what is the minimal delta to support the new capabilities (My personal interest in ACME V2 is around the wildcard certificates).
From: Lukas Schauer [mailto:notifications@github.com]
Sent: Friday, December 15, 2017 3:49 AM
To: lukas2511/dehydrated dehydrated@noreply.github.com
Cc: Leonid Belkind leonid@luminatesec.com; Author author@noreply.github.com
Subject: Re: [lukas2511/dehydrated] ACME v2 Support (#420)
I haven't actually read the spec yet... If not too much has changed this may be implemented in January, certainly only pushed to master after the new endpoint is online. If it's more time consuming I'm guessing late Feb or Mar.
Certificate handling probably doesn't need to be touched a lot, support for wildcard certificates should be easily handled (script-internally) as if they would just be a normal subdomain, I'm kinda hoping that only a few api calls have to be changed.
A great help would be a short summary (if in any way possible...) of the major changes in the protocol.
If a lot has changed a proof of concept shell or python (or some other easily readable language) script with api calls against the new version would be great. Just something that gives a good starting point for figuring out how stuff works, nothing more.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/lukas2511/dehydrated/issues/420#issuecomment-351890016, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXVzSWWmB3qd2rzABmIIg_rGd_5K_boiks5tAc_zgaJpZM4OyNHQ.
@cpu commented on GitHub (Dec 18, 2017):
@lbelkind That's actually two drafts behind the latest :-) Draft-09 is the latest and was cut a few days ago. The Boulder divergences doc is a little bit behind.
@lukas2511 I'd love to eventually sit down and write something like this but I'm still tied up implementing the new protocol & getting ready for launch in Jan/Feb.
Here's a (off-the-top-of-my-head) summary of some major changes that will hopefully help:
In terms of LE specific things to know:
Those are some of the bigger changes that come to mind right off the bat. Definitely not a comprehensive list. I would certainly welcome a community contribution of a more thorough document as a PR to the Let's Encrypt website if someone is feeling like spending more time diffing RFCs :-)
@lukas2511 commented on GitHub (Dec 19, 2017):
@cpu thank you. that doesn't sound too bad, sure a lot of changed things but it actually sounds quite easy to implement and a lot faster and less error-prone than the previous api.
@ginkel commented on GitHub (Jan 5, 2018):
FYI: The staging v2 endpoint is now available: https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605
@rudiedirkx commented on GitHub (Jan 5, 2018):
Only DNS-01 validation for wildcard domains =( That screws with my full automation. Will Dehydrated support plugins for adding DNS APIs?, since every domain provider has its own API.
@jamgregory commented on GitHub (Jan 5, 2018):
@rudiedirkx - Dehydrated already supports DNS hooks (I'm currently using the one for Cloudflare, which works great - https://github.com/kappataumu/letsencrypt-cloudflare-hook). Not sure whether you know Python at all, but you might be able to modify that to your own purposes?
@rudiedirkx commented on GitHub (Jan 5, 2018):
Wait waat! I did not know that. I will reread Dehydrated. Python should work, or any other language if it's just a bash call. Thanks all.
@txr13 commented on GitHub (Jan 6, 2018):
@rudiedirkx You should look into https://github.com/AnalogJ/lexicon as that allows you to use a standardized syntax to interface with multiple DNS providers.
@belliash commented on GitHub (Jan 8, 2018):
Any update soon planned?
@crza commented on GitHub (Jan 8, 2018):
#464 contains support for v2 API.
Regex handling seems to block wildcard domains, but I don't have time to look at that.
@belliash commented on GitHub (Jan 9, 2018):
So its still useless
@txr13 commented on GitHub (Jan 9, 2018):
@belliash That seems harsh, considering how much of the v2 API has been implemented.
@MDXDave commented on GitHub (Jan 10, 2018):
@belliash production endpoint v2 will only be available at 27th february anyway.
@lukas2511 commented on GitHub (Jan 13, 2018):
I have merged @crza's initial implementation. There still seems to be a bit of work required and I didn't yet test if it actually works, but if anybody wants to give it a try, feel free: Replace the CA variable and set API=2 in the config.
@lukas2511 commented on GitHub (Jan 23, 2018):
I was able to test the changes and I was able to acquire a few certificates (including wildcard certificates 🎉) from the staging API.
There are still a few issues, e.g. I had an invalid authorization that I just wasn't able to get rid of, I didn't have much time to look into that issue, it seemed like a server-side bug to me, but I'll have to look into this a bit more.
@cpu commented on GitHub (Jan 23, 2018):
@lukas2511 this is https://github.com/letsencrypt/boulder/issues/3333 and indeed a server-side bug.
@lukas2511 commented on GitHub (Jan 23, 2018):
@cpu thanks for the clarification! definitively saved me from a few more hours of debugging this issue 😃
@chriscpritchard commented on GitHub (Jan 27, 2018):
Worked for me on the staging endpoint, was able to request certs for various subdomains and a wildcard cert.
@rudiedirkx commented on GitHub (Jan 27, 2018):
I'm getting several errors while testing a SAN certificate.
The Dehydrated feedback has changed (maybe because the ACME flow has changed).
Old:
Very obvious that 1 / 4 domains was already validated, and 3 others are being challenged now.
New:
The strange error aside, this feedback is much less clear. Which domains were valid? Which are passed to the dns hook?
And then the strange error of course: challenge not pending..? It tries 1 of the 4, but not the first, but that shouldn't matter.
I'm requesting a new version of an existing certificate (new SAN domains, same CN domain). I think v2 creates a new account automatically? I had to
--register --accept-termsanyway.@rudiedirkx commented on GitHub (Jan 27, 2018):
For a new certificate with a new account, it all works, but that's probably not the usual case after having used Dehydrated before.
@lukas2511 commented on GitHub (Jan 27, 2018):
@rudiedirkx the "challenge not pending" bug is what @cpu was talking about, this is a serverside bug and not a dehydrated bug, the server returns an "invalid" challenge that can't be cleared and dehydrated doesn't expect that to happen as it should never happen.
other than that what exactly is your problem with the output not being clear? it clearly states what domain it's checking. also there are differences on how challenges are generated, they no longer have to be requested domain by domain, they will be delivered by the server as part of the "order", and dehydrated will only tell the server that the challenges are ready (which still happens for each domain)
@rudiedirkx commented on GitHub (Jan 27, 2018):
That's not very clear to me. Is 1 domain already validated? Or all 4? The old method is unambiguous.
The order is also strange:
The DNS hook is called in between validations? Or after the first failure, but before printing that failure?
(Should the challenge for
*.foo.example.combe in_acme-challenge.foo.example.comor_acme-challenge.example.com? I'm getting mixed reports, and mixed results...)Maybe it's all me. This is my first time acmev2ing.
@rudiedirkx commented on GitHub (Jan 27, 2018):
It's getting stranger and stranger:
It's
Responding to challenge for *.example.com...but finds the wrong record at_acme-challenge.wc13.example.com. Why would it be looking at_acme-challenge.wc13.example.com? There must be something wrong with the feedback order.Sometimes all validations succeed and I get a cert, and sometimes not... V1 mode always works always, but no wildcards of course.
@rudiedirkx commented on GitHub (Jan 27, 2018):
There's definitely something wrong, and it's not just the feedback display.
I've definitely never ever validated
wc14.example.combefore, butexample.commight be valid. Dehydrated must thinkwc14.example.comis valid, because it fires the dns hook for*.wc14.example.comand*.example.com.So something in the new V2 flow is wrong. And now I'll stop spamming.
@lukas2511 commented on GitHub (Jan 27, 2018):
@rudiedirkx there was a missing log statement, i added it in
5fd93ea874, it should now be clear what the script is doing.Your last issue seems to be that both
*.wc14.example.comandwc14.example.comwould have to be validated at the same record, this can't be supported withHOOK_CHAINenabled as both records would have been set at the exact same time.I'll add a warning and an automatic fallback to non-chaining behaviour for this. That should solve the issue. With wildcards you shouldn't have too many domains in that certificate, so that shouldn't be much of a problem anyway.
@lukas2511 commented on GitHub (Jan 28, 2018):
Additionally to the hook-chaining problem I found another flaw that might lead to swapped challenges, which in turn will result in invalid authorizations.
I'll be rewriting most of the authorization-handling-code as in it's current form it's basically broken with ACME v2.
Thanks for bringing your issues up @rudiedirkx, wouldn't have found that flaw until much later...
@rudiedirkx commented on GitHub (Jan 28, 2018):
I think ACME and LE support multiple records on the same domain to validatie different domains. A very normal scenario is
*.example.comandexample.com. ACME will require 2 TXT records in_acme-challenge.example.com. It seems (from the many error messages I've read) LE looks at all the TXT records.When you've fixed the challenge swapping problem, I'll try my rubbish again. I really hope HOOK_CHAIN still works in all v2 scenario's, because it's a huge speed gain.
@rudiedirkx commented on GitHub (Jan 28, 2018):
Also, maybe a different issue, wildcard dirs:
Not every OS/fs loves dirs starting with (or even containing) a
*. Maybe replace with-or__or something else less-dangerous-but-still-unique?@rudiedirkx commented on GitHub (Jan 28, 2018):
Also, for a cert with only 1 domain, a wildcard, already validated:
It seems to have worked anyway though...
@rudiedirkx commented on GitHub (Jan 28, 2018):
All my weird challenge validation tests work with your changes, and the feedback is great. Thanks!
@lukas2511 commented on GitHub (Jan 28, 2018):
@rudiedirkx Oh, boulder can validate with multiple TXT records set? I didn't know that, that changes a lot and would also resolve the issue I filed with boulder (https://github.com/letsencrypt/boulder/issues/3405). I'll look into the undefined variable thing and will test the hook chaining thing, if it works I'll remove my "workaround".
@lukas2511 commented on GitHub (Jan 28, 2018):
@rudiedirkx You were right, deploying multiple tokens works perfectly! I'm going to change the loop behaviour a bit so it will work with both HOOK_CHAIN enabled and disabled.
@lukas2511 commented on GitHub (Jan 28, 2018):
Mentioned changes were implemented in
afba7c694c.@rudiedirkx commented on GitHub (Jan 29, 2018):
Seems to work very nicely! Very good feedback. No error if
0 pending challenges. With any domain order. With and without wildcards. Only tried withHOOK_CHAINenabled because duh.I can't wait for Feb 27. I'm guessing the LE servers will be very busy.
@belliash commented on GitHub (Feb 1, 2018):
Waiting 600 seconds to propagate DNS changes
Details:
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Error finalizing order :: Order includes different number of names than CSR specifies",
"status": 403
}
CSR included test.org and *.test.org
So something is not working with CSR, when launching
dehydrated --accept-terms --ocsp --signcsr ./test.csr@lukas2511 commented on GitHub (Feb 2, 2018):
@belliash should be fixed with
45f5c17260@belliash commented on GitHub (Feb 3, 2018):
INFO: Using main config file /etc/dehydrated/config
array(2) {
["file"]=>
string(43) "qrJB4iHDj31jBnoRob5Cupm0h-xmtoGNqC3vYJOy220"
["token"]=>
string(43) "A6jqehG6Tei6JkYo6-4S4xIjXzPnP-3N4XCzzzUfatk"
}
array(2) {
["file"]=>
string(43) "8GvVlpAkr_vESJJNYGDTwXS0oW6LrlwhNsDanZajmJA"
["token"]=>
string(43) "qNipbS_bokld5wp3IYyGn36xixuWNE2MGV6_aIduCCI"
}
Waiting 600 seconds to propagate DNS changes
Details:
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Unable to update challenge :: The challenge is not pending.",
"status": 400
}
As you can see the autorization is for test.org twice... not test.org and *.test.org. Im not usre if its ok or not, but afterwars, my DNS hook script written in PHP has added the following entries:
_acme-challenge.test.org. 60 IN TXT "A6jqehG6Tei6JkYo6-4S4xIjXzPnP-3N4XCzzzUfatk"
_acme-challenge.test.org. 60 IN TXT "qNipbS_bokld5wp3IYyGn36xixuWNE2MGV6_aIduCCI"
so it looks ok to me, but anyway I cannot obtain wildcard certificate.
Any ideas what is wrong?
@lukas2511 commented on GitHub (Feb 3, 2018):
@belliash nothing wrong, that's exactly how it's supposed to be, wildcards are validated at the upper level domain (and there is no way to differentiate which authorization is for which domain, so I can't make it more verbose). the issue you are running into seems to be the boulder bug that was already mentioned in this discussion: https://github.com/letsencrypt/boulder/issues/3333. it's fixed now, but I guess it isn't yet deployed to the staging environment. as a workaround you can delete your account key and register a new one, that should work.
@lukas2511 commented on GitHub (Feb 6, 2018):
I'm closing this as ACME v2 support seems to be quite stable by now 🎉
There are still a few things that might be implemented before the next release (e.g. order-reuse after certain failures would be nice), but main support for the new protocol and wildcard certificates is there and seems to be working fine 😄
If you are having issues with ACME v2 please create new issues instead of replying to this one.
@bviktor commented on GitHub (Feb 17, 2018):
+1 for *.domain.com not being a good idea. Most CAs usually use star_domain_com, we might as well resort to star_domain.com.
@bviktor commented on GitHub (Feb 20, 2018):
How do I tell dehydrated to request a wildcard cert? Can't seem to find this info anywhere. Is it *.domain.com in domains.txt?
@lukas2511 commented on GitHub (Feb 20, 2018):
@bviktor *.domain.com in domains.txt, just like every other domain. but keep in mind that it only works with ACMEv2, so currently only with the staging api.
@bviktor commented on GitHub (Feb 20, 2018):
Yeah, thanks, successfully requested a wildcard one from staging v2, no change needed for the DNS hook, sweet :) Can't wait for prod rollout. Will there be no dns-02? Coz I assumed so.
@rudiedirkx commented on GitHub (Feb 28, 2018):
v2 should be available, no? https://letsencrypt.org/2017/06/14/acme-v2-api.html But where's the directory? And the announcement?
@jobe1986 commented on GitHub (Feb 28, 2018):
LetsEncrypt has delayed the release of the production ACME v2 API end point. See https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html and the linked post at https://community.letsencrypt.org/t/acmev2-and-wildcard-launch-delay/53654 for more information.
@nogweii commented on GitHub (Mar 13, 2018):
And now the ACMEv2 API is public with wildcard support! 🎉 https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579
Congrats on the hard work, LE team! Thanks @lukas2511 for being ahead of this and landing ACMEv2 support already!
@rudiedirkx commented on GitHub (Mar 13, 2018):
Awesome work everyone! Feels goood to use Dehydrated for reals. All worked perfectly!
@jangrewe commented on GitHub (Mar 14, 2018):
@lukas2511 I hope it's appropriate if i hihack this issue, as i think this is the same, or at least a similar issue.
I've updated
dehydrated, changed mydomains.txtto:and now i'm only getting this error:
The DNS-01 challenge was previously working fine, and my DNS slaves do the AXFR well within the wait period i've set (using
pdns_api.sh, by the way), so i'm assuming this is directly related to the ACME v2 endpoint change?@jangrewe commented on GitHub (Mar 14, 2018):
I just checked with only the wildcard domain, so my
domains.txtlooked like thisThis works, but i'd still like to have both the apex and the wildcard in the same cert, so i tried with the apex, the wildcard and also defining an alias:
And this now also works!
So it looks like the alias is mandatory if you're using a wildcard?
@jangrewe commented on GitHub (Mar 14, 2018):
Another observation, for a different domain: It only works if i first request the wildcard cert with an alias, and then add the apex and renew the certificate with the additional name (which doesn't need the alias anymore).
So for every domain i need two separate runs,
first:
then:
@bviktor commented on GitHub (Mar 14, 2018):
Yes, the alias is mandatory for wildcard, see https://github.com/lukas2511/dehydrated/issues/483
@jangrewe commented on GitHub (Mar 14, 2018):
Yes, i know that it's mandatory if you use only a wildcard, but it seemed as if it was also mandatory if you're using a wildcard (as the SAN only, so in theory no alias would be required) together with a regular domain name - because it worked for me on the second try, after successfully requesting a cert for only the wildcard first.
But...
... as my most recent comment showed, that assumption by me is not true - it just doesn't work at all (for me) if i request a cert for a regular domain with the wildcard as a SAN (with or without the alias), unless i first request it for only the wildcard (using the alias), and then for the domain and the wildcard combined (either with or without alias, again).
btw, is your (lukas2511) Amazon Wishlist still up to date? ;-)
@rudiedirkx commented on GitHub (Mar 14, 2018):
Certificates like
work perfectly for me. Does your DNS hook add and keep 2 records?
@jangrewe commented on GitHub (Mar 14, 2018):
I've been using pdns_api.sh for quite some time now, and it worked fine "until yesterday". Some certs of mine have/had dozens of SANs, so that would mean that it's only broken for wildcards then...
I also wonder why it works on subsequent runs with multiple names, just not for the initial run.
@txr13 commented on GitHub (Mar 14, 2018):
Somebody else has the same issue with pdns in #504. Probably safe to say there's something wrong with either the hook or pdns itself.
Subsequent runs with multiple names are probably re-using the validations done from earlier, so you don't have to re-validate them simultaneously.
@lukas2511 commented on GitHub (Mar 14, 2018):
thanks @txr13, and @jangrewe yes, my wishlist is always up to date ;)
I'm going to lock this conversation so that new issues will land in their own tickets instead of this big collection, makes it easier for me (and others) to find duplicates 😄