To support v2 wildcard cert, we need to add 2 txt records for the same domain.
for example:
_acme-challenge.example.com TXT "this is txt value 1"
_acme-challenge.example.com TXT "this is txt value 2"
In many dns api hooks, in the dns_xx_add() function, they try to UPDATE the existing txt record, instead of ADD a new record.
This was a good practice for ACME v1, but it's not good in ACME v2.
In ACME v2, we just need to add new txt record all the time in the dns_xx_add() function,
And in the the dns_xx_rm() function, we must delete the txt record according to the specified txt value.
Test example:
acme.sh --issue --test -d example.com -d *.example.com
Please make sure this works, and the 2 txt records are removed after the cert is issued.
See my changes:
https://github.com/Neilpang/acme.sh/commit/ea25492c2823a4971b3d2eb28fa0dcd2b5105db9#diff-51fe23dd1a90a481487dbca5b9c3ae24
https://github.com/Neilpang/acme.sh/commit/72f54ca6c13c33943aafbacaee03423907f5e738#diff-d48ca70b90232acffb2b5b9d1ec2938a
https://github.com/Neilpang/acme.sh/commit/584fb2904b6b63cf13d71ba20fa184ade62730a0#diff-f272833bc0ccf326ea343539e829f1d3
@wpk- Please update the rm function of dns_ad hook.
@baiyangliu please support the rm function for dns_ali hook.
@martgras please make sure dns_azure hook works in this way.
@boyanpeychev please update dns_cloudns hook
@Neilpang please accept this pull request and I will proceed with the wildcard implementation:
https://github.com/Neilpang/acme.sh/pull/1094
@boyanpeychev accepted, please go ahead.
@pho3nixf1re please update dns_dnsimple hook
@dkerr64 please update dns_freedns.sh
@fcrozat please update dns_gandi_livedns.sh
@justmwa please update dns_me.sh
@justmwa please also update dns_nsone.sh
@magna-z please update dns_pdns.sh
@Aarup please update dns_unoeuro.sh
aws work. Thanks a lot
I don't think any changes are needed but will double check next week when I'm back
From: drybalkadk notifications@github.com
Sent: Wednesday, February 14, 2018 4:49:57 PM
To: Neilpang/acme.sh
Cc: Martin Grasruck; Mention
Subject: Re: [Neilpang/acme.sh] Update dns api to support v2 wildcard cert (#1261)
aws work. Thanks a lot
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Neilpang/acme.sh/issues/1261#issuecomment-365649473, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYjgXW3X7a88xrFvZiuuvKzzoVXrt3oaks5tUwCkgaJpZM4SDoO5.
@martgras thank you.
no changes needed for dns_cloudns.sh
@boyanpeychev There is an updating logic in the dns_cloudns_add() function.
Are you sure no changes are needed there?
Please make sure this case is passing:
acme.sh --issue --test -d example.com -d *.example.com
Works as is because there's only one TXT sent from what I can see in logs. And since LE accepts it, they changed their mind about the double TXT record ?
Message to those who think it works "as is", try with a subdomain ;) (unless it's not officially supported?)
i.e foo.example.com. Actually it's only an issue with one API so far, need to dig further.
@justmwa no, never.
please use a new domain to test.
acme.sh --issue -d sub.domain.com -d *.sub.domain.com
Fixed the Azure hook only 1 DNS record was added: #1287
@Neilpang, yes, it is tested with completely new domain and sub-domain for Let's Encrypt and it works both for the root domain name and with a sub-domain. The records are added successfully.
However, I do see one problem not related to the cloudns.net api - sometimes the given token is not accepted by Let's Encrypt, even it is resolved absolutely properly. Here is example log:
test.log
The TXT records requested to be added is with token: GUFN5HSXlmothHwsZWbCZW-SfgCaQYCTTB874fZ6Ijw
The same token is found by Let's Encrypt, but reported as invalid. Please check you too.
I don't understand the cloudns api well enough but I suspect you run into the the same problem I had with Azure in #1287
Instead of creating 2 txt entries my code was first creating
_acme-challenge.test.cloudns.biz. 10 IN TXT "DyLeOblvCb1I9DqZ2BlB0fdQYsA3or4WVdZN139KaHg" and then the second call to dns_azure_add changed this txt record to
_acme-challenge.test.cloudns.biz. 10 IN TXT "GUFN5HSXlmothHwsZWbCZW-SfgCaQYCTTB874fZ6Ijw"
therefore the validation failed
Make sure you really create 2 entries instead of updating the existing one
Basically I have to use a Json body like this for the Azure DNS REST API call
{
"properties": {
"TTL": 10,
"TXTRecords": [
{ "value": ["DyLeOblvCb1I9DqZ2BlB0fdQYsA3or4WVdZN139KaHg"] },
{ "value": ["GUFN5HSXlmothHwsZWbCZW-SfgCaQYCTTB874fZ6Ijw"] }
]
}
}
you should see something like this when checking with dig
dig -t txt _acme-challenge.test.cloudns.biz
_acme-challenge.test.cloudns.biz. 10 IN TXT "DyLeOblvCb1I9DqZ2BlB0fdQYsA3or4WVdZN139KaHg"
_acme-challenge.test.cloudns.biz. 10 IN TXT "GUFN5HSXlmothHwsZWbCZW-SfgCaQYCTTB874fZ6Ijw"
Thanks for the hint. Fixed. Pull request submitted.
@boyanpeychev It's not enough yet.
In the rm() function, you must remove the record by the exact txt value.
In the rm() function:
record_id=$(_dns_cloudns_get_record_id "$zone" "$host")
But the _dns_cloudns_get_record_id() function seems not considering the txt value.
@Neilpang the same is true for Azure but why does it matter?
first call to dns_azure_rm :
DELETE https://management.azure.com/subscriptions/../dnszones/example.com/TXT/_acme-challenge.somesub1.test?api-version=2017-09-01
http response code 200
second call:
DELETE https://management.azure.com/subscriptions/../dnszones/example.com/TXT/_acme-challenge.somesub1.test?api-version=2017-09-01
http response code 204
so yes the first call removes the record already but I don't see the problem with this approach
@martgras Yes, it doesn't matter if it's only you that use the domain to verify the cert.
If there are multiple people validating the same domain, you may remove the txt domain from others.
Especially we will soon merge the support for dns alias mode: https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode
So, it's strongly recommended that you only remove the txt record added by you.
@martgras
In the dns azure api, the rm() function:
body="{\"properties\": {\"TTL\": 3600, \"TXTRecords\": [{\"value\": [\"$txtvalue\"]}]}}"
I think the txt value is considered.
@Neilpang can I use awk, if not, let me know what you prefer for the parse of JSON?
@boyanpeychev Sorry, I don' want to import anymore dependencies, like: awk.
https://github.com/Neilpang/acme.sh/wiki/DNS-API-Dev-Guide#5-process-the-api-response
See examples I process json:
https://github.com/Neilpang/acme.sh/blob/dev/dnsapi/dns_ali.sh#L188
https://github.com/Neilpang/acme.sh/blob/dev/dnsapi/dns_gd.sh#L52
It may help you.
Thanks.
@Neilpang this is a pain - lots of ugly Json parsing but I hope I got it now once I get rid of my usual travis format errors
@Neilpang the txt value was not considered this body was never sent and would have been ignored anyways - was just a leftover when I copied the code from add.
Azure_dns is finally ok now.
BTW: I understand you don't want new dependencies and it makes sense. jq would have been my preference
@Neilpang cloudns api is updated and tested with multiple TXT records and it deletes only the proper records.
@fcrozat @Neilpang - Regarding Gandi Live DNS (http://doc.livedns.gandi.net/#work-with-domains), it seems this API isn't able to remove records by value, all we can do is "DELETE /domains/{DOMAIN}/records/{NAME}/TXT" (remove all TXT records for a name). For adding records, indeed, method POST should do a better job than method PUT (update a record).
A possible workaround would be to first generate a list of all TXT records for {NAME} (GET), edit list by removing TXT records to delete, erase all TXT records for {NAME} (DELETE) and finally add (POST) edited list. But I believe it's a lot of work for not so much of a benefit (and we couldn't get atomicity/locking on this process, especially if user choose a long duration for Le_DNSSleep).
I am starting to look at this but running into a issue. from debug....
[Wed Mar 7 10:12:41 EST 2018] Using ACME_DIRECTORY: https://acme-v02.api.letsencrypt.org/directory
[Wed Mar 7 10:12:41 EST 2018] _init api for server: https://acme-v02.api.letsencrypt.org/directory
[Wed Mar 7 10:12:41 EST 2018] GET
[Wed Mar 7 10:12:41 EST 2018] url='https://acme-v02.api.letsencrypt.org/directory'
[Wed Mar 7 10:12:41 EST 2018] timeout=
[Wed Mar 7 10:12:41 EST 2018] _CURL='curl -L --silent --dump-header /mnt/kd/acme/http.header -g '
[Wed Mar 7 10:12:42 EST 2018] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
[Wed Mar 7 10:12:42 EST 2018] ret='6'
[Wed Mar 7 10:12:42 EST 2018] Can not init api.
I am using OpenDNS as my DNS service and it reports that there is no A record for this URL. Any thoughts?
Try entering acme-v02.api.letsencrypt.org
into https://www.ultratools.com/tools/dnsLookupResult
and get "no record found" for everything.
@dkerr64 please add --test
Okay, thank you. That got me past that issue. The freedns method is NOT working with the v2 version... the code made assumption that only one TXT record would be created at a time. Therefore I will need to work on fixing it. Not sure how easy that will be, will let you know.
@Neilpang support added for FreeDNS API, see PR #1343
Thank you.
Would wildcard certs work in --webroot mode?
Also, are partial wildcards supported? Like foo-*.example.com
Thanks.
No. Let's Encrypt wildcard certs will only be validated via dns01 method
--
Fernando Miguel
On 12 Mar 2018 05:00, "rihadik" notifications@github.com wrote:
Would wildcard certs work in --webroot mode?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Neilpang/acme.sh/issues/1261#issuecomment-372194146,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKRrsI8JTYgcJMN74qw1iWk4lHR91z-ks5tdgDlgaJpZM4SDoO5
.
What about through dns_aws? Is it supported or will it be?
@rihadik from my quick testing using LE staging servers and acme v2, it worked without issues.
Great, thank you. I think partials are currently not possible:
--issue --dns dns_aws -d foo-*.example.com
according to logs acme.sh contacts LE v01 API and naturally gets an error due to invalid characters in domain name. Probably acme.sh expects a domain to start with * and have nothing more to trigger wildcard logic. But there's such a thing as a partial wildcard, please see here: https://en.wikipedia.org/wiki/Wildcard_certificate#Examples
Is this a acme.sh limitation or LE's?
@rihadik limitation should be from the both sides. There is no dns provider in the list, who can give you a TXT record for foo-*.example.com and I do not know about any CA who is providing such partial ssl certificates.
What about en.*.example.com? It isn't a partial wildcard if you ask me, but it is also not supported.
update: just checked, no, this form is specifically disallowed.
@rihadik I had fixed aws api for wildcard.
Letsencrypt only supports one style of wildcard: *.example.com. No other format is supported.
--issue --dns dns_aws -d *.example.com --test
should work.
you cant combine partials with wildcard, i dont think any browser would support that
@Tungstene @Neilpang @fcrozat
I've just succeeded to get a wildcard certificate with gandi_live_dns.sh.
It's deployed here: https://try.test.edno.moe/
The "normal" site is here: https://www.edno.moe/
acme.sh installed from github today:
~/.acme.sh/*.test.edno.moe$ acme.sh -v
https://github.com/Neilpang/acme.sh
v2.7.7
Latest in the commit log is this:
commit 14bb60c61ffd83779e3e18fe5ab79ad328edb7db
Merge: 8ab8a6e 0f120c4
Author: neil <[email protected]>
Date: Wed Mar 14 20:11:55 2018 +0800
Merge pull request #1370 from anabis/patch-1
fix syntax error missing space
P.S. Great project! Thank you all for the effort.
I'm trying the following, which is failing:
acme.sh --issue --dns dns_aws -d ceregatti.org -d ceregatti.net -d ceregatti.com -d '*.ceregatti.org' -d '*.ceregatti.net' -d '*.ceregatti.com' --debug --log
Here's the log:
Not sure what to make of that.
I've already issued this cert just fine using acme.sh but without --dns dns_aws. I simply created the DNS entries manually. See it here: https://ceregatti.org. Note the Subject Alternative Names are all present:
Just pointing out that wildcard part itself is working just fine! I never thought I'd see the day!
Daniel
Create new order error. Le_OrderFinalize not found.
Fernando Miguel
On 14 Mar 2018 22:26, "Daniel Ceregatti" notifications@github.com wrote:
I'm trying the following, which is failing:
acme.sh --issue --dns dns_aws -d ceregatti.org -d ceregatti.net -d
ceregatti.com -d '.ceregatti.org' -d '.ceregatti.net' -d '*.
ceregatti.com' --debug --logHere's the log:
screen-exchange.txt
https://github.com/Neilpang/acme.sh/files/1813327/screen-exchange.txtNot sure what to make of that.
I've already issued this cert just fine using acme.sh but without --dns
dns_aws. I simply created the DNS entries manually. See it here:
https://ceregatti.org. Note the Subject Alternative Names are all present:[image: capture]
https://user-images.githubusercontent.com/384719/37434069-982ca764-279b-11e8-873a-3f85f94adfeb.PNGJust pointing out that wildcard part itself is working just fine! I never
thought I'd see the day!—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Neilpang/acme.sh/issues/1261#issuecomment-373195773,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKRrnM1BcCN7DnbIHr6cWRjhh-I4y5wks5teZkygaJpZM4SDoO5
.
@DanielCeregatti can you please try with --debug 2 to reproduce the issue again ?
@cpu Would you please take a look at @DanielCeregatti 's screen-exchange.txt file? it's a log from acme.sh
From line 89:
[Wed Mar 14 21:54:13 UTC 2018] url='https://acme-v02.api.letsencrypt.org/acme/new-order'
[Wed Mar 14 21:54:13 UTC 2018] payload='{"identifiers": [{"type":"dns","value":"ceregatti.org"},{"type":"dns","value":"ceregatti.net"},{"type":"dns","value":"ceregatti.com"},{"type":"dns","value":"*.ceregatti.org"},{"type":"dns","value":"*.ceregatti.net"},{"type":"dns","value":"*.ceregatti.com"}]}'
[Wed Mar 14 21:54:13 UTC 2018] POST
[Wed Mar 14 21:54:13 UTC 2018] _post_url='https://acme-v02.api.letsencrypt.org/acme/new-order'
[Wed Mar 14 21:54:13 UTC 2018] _CURL='curl -L --silent --dump-header /home/daniel/.acme.sh/http.header -g -H "Content-Type: application/jose+json" '
[Wed Mar 14 21:54:13 UTC 2018] _ret='0'
[Wed Mar 14 21:54:13 UTC 2018] code='400'
We send request to new-order url, but just got 400 code. Is there any chance you can check the log from LE server end? The UTC time and the domains are all in in the log. It can help me know whether acme.sh sent the correct JWS headers.
Thanks.
@cpu Would you please take a look at @DanielCeregatti 's screen-exchange.txt file? it's a log from acme.sh
@Neilpang :+1: I will take a look shortly and report back. Note that you should receive a full problemDetails response from newOrder that will have an error code and a detail message as well. Does acme.sh log this? It would be very valuable information for failures.
[Wed Mar 14 21:54:13 UTC 2018] url='https://acme-v02.api.letsencrypt.org/acme/new-order'
[Wed Mar 14 21:54:13 UTC 2018] payload='{"identifiers": [{"type":"dns","value":"ceregatti.org"},{"type":"dns","value":"ceregatti.net"},{"type":"dns","value":"ceregatti.com"},{"type":"dns","value":".ceregatti.org"},{"type":"dns","value":".ceregatti.net"},{"type":"dns","value":"*.ceregatti.com"}]}'
I was able to find this request and the 4XX response. As expected, Boulder returned a problem details object that says what the error was:
2018-03-14T21:54:13.739534+00:00 boulder-wfe2[XXXX]: JSON={"RealIP":"XX.XX.XX.XX","Endpoint":"/acme/new-order","Method":"POST","Errors":["400 :: malformed :: No Key ID in JWS header"],"UserAgent":"acme.sh/2.7.8 (https://github.com/Neilpang/acme.sh)","Code":400}
I don't have access to the POST body to decode the JWS but it seems likely that acme.sh was sending a JWS with an embedded key as opposed to a protected key ID header.
Hope this helps,
Here's the log with --debug 2:
@cpu thank you, we have logged such error message like you saw.
I've updated to the latest version of dns_pdns.sh, but still only one txt record is created.
so @FernandoMiguel, dev-master is working with Gandi Live DNS and let's encrypt wildcards ?
@tristanbes hun!?
I'm referring to your comment. https://github.com/Neilpang/acme.sh/issues/1261#issuecomment-373158012
My question is did you manage to issue wildcards certificate using this client with Gandi LiveDNS ? This issue tells otherwise. I would love to get your feedback.
@tristanbes i've issued many wildcard certs, but using aws and Cloudflare APIs.
dont have an account with gandi.
you are probably better contacting that plugin maintainer than a random person like myself.
also, you can easily try for yourself, and report any issues you may have on a new ticket
Sorry, guess I'm not awake. Would meant to ping @zloster who originally posted the comment I gave you :(
@tristanbes Yes, I was able to issue a wildcard certificate using this client and Gandi LiveDNS. The important detail is that I'm issuing only a wildcard certificate. No other domain names involved.
Inspect the certificate for https://try.test.edno.moe. It's for *.test.edno.moe domain.
mhhh ok. So the integration with GandiLiveDNS still needs work.
Thanks @zloster for your feedback. :-)
It looks like there's a problem renewing or issuing (wildcard?) certs on CF.
$ sudo -u acmesh ~acmesh/acme.sh --home ~acmesh/ --renew --dns dns_cf -d example.com -d '*.example.com'
[Tue May 15 10:13:51 UTC 2018] Renew: 'example.com'
[Tue May 15 10:13:51 UTC 2018] Multi domain='DNS:example.com,DNS:*.example.com'
[Tue May 15 10:13:51 UTC 2018] Getting domain auth token for each domain
[Tue May 15 10:13:53 UTC 2018] Getting webroot for domain='example.com'
[Tue May 15 10:13:53 UTC 2018] Getting webroot for domain='*.example.com'
[Tue May 15 10:13:53 UTC 2018] Found domain api file: /usr/local/etc/acme.sh/dnsapi/dns_cf.sh
[Tue May 15 10:13:54 UTC 2018] invalid domain
[Tue May 15 10:13:54 UTC 2018] Error add txt for domain:_acme-challenge.example.com
[Tue May 15 10:13:54 UTC 2018] Please check log file for more details: /usr/local/etc/acme.sh//acme.sh.log
It looks like "invalid domain" is due to _get_root() failing in dns_cf.sh
Sorry, it looks like it was a misconfiguration which wasn't obvious from logs or --debug calls. I simply added echo "$response" in _get_root() and saw the error:
{"success":false,"errors":[{"code":9103,"message":"Unknown X-Auth-Key or X-Auth-Email"}],"messages":[],"result":null}
{"success":false,"errors":[{"code":9103,"message":"Unknown X-Auth-Key or X-Auth-Email"}],"messages":[],"result":null}
dns_me doesn't work with wildcard certs. It looks like it fails detecting the root zone, and errors out with "invalid domain"
mhhh ok. So the integration with GandiLiveDNS still needs work.
Thanks @zloster for your feedback. :-)
Using Gandi for a domain.tld & *.domain.tld cert. It works, but I have to launch acme.sh two times in "quick" burst : it fails first, and pass on second time. Same with renewal cron job.
same for us @saymonz using GandLiveDNS, it randomly fails, running it a second time "fixes" it.
I ran into a similar problem with FreeDNS and had to code around it. Not sure if you are running into exactly the same reasons for the "required twice" but see comment in the code for dns_freedns.sh around line 59... https://github.com/Neilpang/acme.sh/blob/c31db83b26afa1468aa00aafd63c64f2c410811d/dnsapi/dns_freedns.sh#L59-L63
David
after the merge in 83a040722e5b0c132003f7f53d09867fcd05d13c.
Hi there!
I am using https://dyn.com/ They support nsupdate method but they require both TXT records to be added in a single update. Basically, they do remove all matching records prior to adding the new ones.
I hacked acme.sh and dnsapi/dns_nsupdate.sh so they work for me, but the hack is pretty ugly, so I am ashamed to post it as a PR :)
In a nutshell: In the acme.sh.issue() I check if the API supports .*_multi_add command.
If the command is supported then in the for ventry in $ventries loop I am collecting an array of values instead of sending individual requests. Then I execute one API call after the loop and pass to the API the collected domain+txt pairs.
I wonder if acme gurus could properly implement the feature allowing adding several TXT records in one update session?
I'm trying to get a wildcard certificate using dns_pdns
Logs tell me that two records are added
[Die Mai 7 09:41:24 CEST 2019] Found domain api file: /root/.acme.sh/dnsapi/dns_pdns.sh
[Die Mai 7 09:41:24 CEST 2019] Adding record
[Die Mai 7 09:41:25 CEST 2019] Found domain api file: /root/.acme.sh/dnsapi/dns_pdns.sh
[Die Mai 7 09:41:25 CEST 2019] Adding record
But as the dns server only shows one value I assume that dns_pdns is not ready for v2 wildcard certs. First post in this report shows dns_pdns not as fixed yet.
Does anyone have a working dns_pdns for v2 wildcard certificates?
output of acme.sh sez that the token is "not valid yet" and acme.sh waits for 10s to repeat the check and fails again (in a loop)
[Die Mai 7 09:53:01 CEST 2019] Checking REDACTED.ch for _acme-challenge.REDACTED.ch
[Die Mai 7 09:53:01 CEST 2019] Not valid yet, let's wait 10 seconds and check next one.
But according to the pdns server at least one record for _acme-challenge.REDACTED.ch does exist
did some more diging in dns_pdns code. It seems to me that the script cannot get the list of already existing challenges as the pdns api uri only gives back a "500 Internal server error"
curl -X GET -H 'X-API-Key: MY_API_KEY' http://127.0.0.1:8081/api/v1/servers/localhost/zones/mydomain.tld
Any pdns user here who can verify if that URI still works or not? I'm using pdns server 4.1.8
It's the only query that does not work so far. All others seem to be fine
dns_pdns is finally working fine. Was never a acme problem but one with the pdns server. We use mysql backend for pdns and our frontend application inserts TXT records like this
v=spf1 mx -all
pdns server then packs the string into " and " before returning it in queries to clients. But the API interface does not perform this step and then sees incorrect TXT records in the zone and therefore the API endpoint returns with the server error. Which leads acme.sh to the assumption that no other challenge exists in the zone.
Long story short: if using pdns with mysql backend one has to ensure that TXT records are inserted like this
"v=spf1 mx -all"
then pdns api is happy
@Neilpang
from my point of view dns_pdns works correctly with LE v2 wildcard certificates.
@jahlives Thanks.
after merging #2852.
Most helpful comment
And it's live
https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579