Replies: 4 comments
-
|
Hey @BAM279, I remembered having looked into a similar issuer a while ago: #1120, also in combination with One option (workaround, maybe?) you could try is to make the CA use a different/specific DNS resolver using the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks very much for reading my post. I am running step-ca on a dedicated VM: root@stepca:~# uname -a I have a docker-compose project with two services, acme-dns and acmeproxy. I am not actually using acmeproxy for anything yet, but it has its own SSL cert auto-request which is where the acme request is originating for the purpose of this example. When the acmeproxy container is started, it will automatically initiate an acme certificate request to stepca (ca.internal.lan) whilst also calling acme-dns to auto-register and update the required dns records. The events from docker are as follows, with acmeproxy_1 and acme-dns_1 being the respective service logs: acmeproxy_1 | [Oct 9 12:57:08] INFO ssl.auto: [acmeproxy.2.internal.lan] Obtaining bundled SAN certificate interval=2s timeout=1m0s Here is a tcpdump from stepca: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes After the above CNAME is returned, stepca then continues searching via the other search domains from the /etc/resolv.conf: root@stepca:~# cat /etc/resolv.conf 13:39:18.902160 ens192 Out IP 10.2.40.225.53338 > 10.2.53.3.53: 6299+ [1au] TXT? _acme-challenge.acmeproxy.2.internal.lan.2.internal.lan. (90) I can do a separate DNS lookup on another system to confirm that acme-dns has registered and is hosting the assocated TXT:
96efadd0-6a34-4a9f-9867-e4d69e05e302.acmedns.2.internal.lan text = "6fdv-ajNYqu_mWBeGHf5FPF7Ki3bssDsVpEdkXPF0FY" On looking through the above, acme-dns retains/cycles two TXT records. Is there a limitation on how many TXT records Step-CA will check against? Maybe this is the problem? Many thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I noticed that the TXT record advised as being updated by acme-dns (timestamp acme-dns_1 | time="2023-10-09T12:57:08Z" ) didnt match with the result of my manual lookup at the end of the last message - this would have certainly been the issue, but I provided an old DNS lookup, the correct values should have been:
96efadd0-6a34-4a9f-9867-e4d69e05e302.acmedns.2.internal.lan text = "YFECi4SrKVALZQod6cOfAZW9RsFYMEais0268OHDblA" Again, acme-dns added two new records and wondering if this could be something step-ca doesnt like? Seems the "current" TXT record is always returned as the 2nd one in the output. Does step-ca only check the 1st returned TXT record and ignore any others? Thanks and sorry for confustion here. |
Beta Was this translation helpful? Give feedback.
-
|
I also tried on the docker server to generate a wildcard cert for *.docker.2.internal.lan using acme.sh client and the response confirms a DNS query issue: [Mon 9 Oct 17:54:41 BST 2023] response='{"identifier":{"type":"dns","value":"docker.2.internal.lan"},"status":"pending","challenges":[{"type":"dns-01","status":"pending","token":"GfjadiUCMkcRl08M23YN9VuEeYKF9Tpe","url":"https://ca.internal.lan/acme/stepca/challenge/Rmh6LwedDeSl4QYJ0Ar78FNnzzy1JJR2/aFJ861B2r3vK6t9Bims0iHQdBfqQxAL3","error":{"type":"urn:ietf:params:acme:error:dns","detail":"There was a problem with a DNS query during identifier validation"}}],"wildcard":true,"expires":"2023-10-10T16:54:13Z"}' From the step-ca systemd service (logs from a slightly later attempt but same error): Oct 09 18:06:34 stepca step-ca[6149]: time="2023-10-09T18:06:34+01:00" level=info duration=4.677025ms duration-ns=4677025 fields.time="2023-10-09T18:06:34+01:00" method=POST name=ca nonce=ajM5RDVOaFRLZWtodnAxUlVCYnRVb0xnUVZTa25Rc2o path=/acme/stepca/authz/wEcLNiL5edlqOWVgN6p3na4DyiaW4gxu protocol=HTTP/2.0 referer= remote-address=10.2.60.2 request-id=cki366hg4qftn285mge0 response="{"identifier":{"type":"dns","value":"docker.2.internal.lan"},"status":"pending","challenges":[{"type":"dns-01","status":"pending","token":"5lbG5Drh7rjAvF1dyl6hFacWbTnEUQAJ","url":"https://ca.internal.lan/acme/stepca/challenge/wEcLNiL5edlqOWVgN6p3na4DyiaW4gxu/TLKj47uqrhN5ecWU1a3FDUiWdOhMQstg","error":{"type":"urn:ietf:params:acme:error:dns","detail":"There was a problem with a DNS query during identifier validation"}}],"wildcard":true,"expires":"2023-10-10T17:06:28Z"}" size=478 status=200 user-agent="acme.sh/3.0.7 (https://github.com/acmesh-official/acme.sh)" user-id= Thanks, |
Beta Was this translation helpful? Give feedback.
-
Hi,
I am using the acme.sh client with the acme-dns api module to answer dns-01 challenges successfuly with Lets Encrypt.
I wish to use step-ca instead of Lets Encrypt for my private internal CA. I have already tested my step installation with http-01 challenges and these work fine by setting my step-ca acme provisioner URL as the default server in acme.sh.
I am now trying to use the same acme-dns api module for dns-01 challenges via step-ca using acme.sh.
Acme-dns (https://github.com/joohoi/acme-dns) relies on manual addition of CNAME record on the internal DNS to redirect _acme-challenge TXT record lookups to its own authoritative internal domain where its own private DNS can return the correct TXT record. As above, this mechanism works perfectly with Lets Encrypt.
However, the issue seems to be that when step-ca does the _acme-challenge TXT record lookup, when the expected result is instead the CNAME, step-ca does not follow this in order to resolve the TXT record hosted by acme-dns server, and instead continues looking for the TXT record against the other configured search domains in the local /etc/resolv.conf file.
As the Lets Encrypt dns-01 challenge follows the returned CNAME (and EFF even talks about this method, as well as acme-dns in the following article https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation), is there some other security feature or configuration option that must be set in step-ca that would facilitate the following of CNAME records?
Many thanks,
BAM
Beta Was this translation helpful? Give feedback.
All reactions