ACME v2 Support #420
Comments
|
Is your mic on? |
|
Yes! I have a few use cases for wildcard certificates too, so this will definitively get implemented! |
|
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.com<mailto: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 GitHub<#420 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXVzSfParsPJJ9oBTpPq0yXIfcqGPj-dks5tAF4igaJpZM4OyNHQ>.
|
|
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. 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. |
|
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 GitHub<#420 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXVzSWWmB3qd2rzABmIIg_rGd_5K_boiks5tAc_zgaJpZM4OyNHQ>.
|
@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 :-) |
|
@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. |
|
FYI: The staging v2 endpoint is now available: https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605 |
|
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. |
|
@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? |
|
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. |
|
@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. |
|
Any update soon planned? |
|
#464 contains support for v2 API. |
|
So its still useless |
|
@belliash That seems harsh, considering how much of the v2 API has been implemented. |
|
@belliash production endpoint v2 will only be available at 27th february anyway. |
|
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. |
|
I was able to test the changes and I was able to acquire a few certificates (including wildcard certificates 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. |
@lukas2511 this is letsencrypt/boulder#3333 and indeed a server-side bug. |
|
@cpu thanks for the clarification! definitively saved me from a few more hours of debugging this issue |
|
Worked for me on the staging endpoint, was able to request certs for various subdomains and a wildcard cert. |
|
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 |
|
For a new certificate with a new account, it all works, but that's probably not the usual case after having used Dehydrated before. |
|
@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) |
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 Maybe it's all me. This is my first time acmev2ing. |
|
It's getting stranger and stranger: It's Sometimes all validations succeed and I get a cert, and sometimes not... V1 mode always works always, but no wildcards of course. |
|
There's definitely something wrong, and it's not just the feedback display. I've definitely never ever validated So something in the new V2 flow is wrong. And now I'll stop spamming. |
|
@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 (letsencrypt/boulder#3405). I'll look into the undefined variable thing and will test the hook chaining thing, if it works I'll remove my "workaround". |
|
@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. |
|
Mentioned changes were implemented in afba7c6. |
|
Seems to work very nicely! Very good feedback. No error if I can't wait for Feb 27. I'm guessing the LE servers will be very busy. |
Details: CSR included test.org and *.test.org |
|
INFO: Using main config file /etc/dehydrated/config
array(2) {
Details: 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" so it looks ok to me, but anyway I cannot obtain wildcard certificate. |
|
@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: letsencrypt/boulder#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. |
|
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. |
|
+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. |
|
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? |
|
@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. |
|
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. |
|
v2 should be available, no? https://letsencrypt.org/2017/06/14/acme-v2-api.html But where's the directory? And the announcement? |
|
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. |
|
And now the ACMEv2 API is public with wildcard support! Congrats on the hard work, LE team! Thanks @lukas2511 for being ahead of this and landing ACMEv2 support already! |
|
Awesome work everyone! Feels goood to use Dehydrated for reals. All worked perfectly! |
|
@lukas2511 I hope it's appropriate if i hihack this issue, as i think this is the same, or at least a similar issue. 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 |
|
I just checked with only the wildcard domain, so my This 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! |
|
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, then: |
|
Yes, the alias is mandatory for wildcard, see #483 |
|
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? ;-) |
|
Certificates like work perfectly for me. Does your DNS hook add and keep 2 records? |
|
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. |
|
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. |
lbelkind commentedAug 9, 2017
In January 2018 Lets Encrypt will launch a new ACME v2 Endpoint that will allow wildcard certificates.
Any plans to implement this?
The text was updated successfully, but these errors were encountered: