interactsh: Errors in TXT propagation during SSL certificate update/installation
The certificate update randomly fails due to delays/issues in the TXT record propagation containing the challenge:
# ./interactsh-server -domain abcd.efg -ip xxx.xxx.xxx.xxx -listen-ip xxx.xxx.xxx.xxx
2021/12/15 14:24:28 Creating new order for domains: [*.abcd.efg abcd.efg]
2021/12/15 14:24:28 Order created: https://acme-v02.api.letsencrypt.org/acme/order/123456789/123456789
2021/12/15 14:24:28 Fetching authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/123456789
2021/12/15 14:24:28 Fetched authorization: abcd.efg
2021/12/15 14:28:28 Updating challenge for authorization abcd.efg: https://acme-v02.api.letsencrypt.org/acme/chall-v3/123456789/123456789
2021/12/15 14:28:59 An error occurred while applying for an certificate, error: could not generate new certs: error updating authorization abcd.efg challenge: acme: error code 400 "urn:ietf:params:acme:error:dns": During secondary validation: DNS problem: query timed out looking up TXT for _abcd.efg
2021/12/15 14:28:59 Could not generate certs for auto TLS, https will be disabled
2021/12/15 14:28:59 Listening on DNS, SMTP and HTTP ports
$ dig abcd.efg txt # from another box
; <<>> DiG 9.16.1-Ubuntu <<>> hackwithautomation.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15605
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;abcd.efg. IN TXT
;; ANSWER SECTION:
abcd.efg. 0 IN TXT ""
;; Query time: 8 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Dec 15 13:32:01 UTC 2021
;; MSG SIZE rcvd: 107
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 4
- Comments: 15 (6 by maintainers)
@mbrownnycnyc Thanks for looking into this. I confirm the server will pick up both the certificate and private key in those locations but will attempt to renew them starting 30 days before the expiration, as recommended by let’s encrypt. Unfortunately, I couldn’t obtain a new certificate yet due to secondary validation failure. Anyway, the workaround that you provided should generally work.
I’m able to workaround this issue by placing the public cert chain at
/root/.config/interactsh/cert.crt
and private key at/root/.config/interactsh/cert.key
. This doesn’t appear to be documented, but I located it withstrace
.I generated a cert for
fqdn.com
viacertbot
and following the procedure (create a TXT record at the NS, verified it’s visibility to https://unboundtest.com):Then I created two links:
I invoked
interactsh
with:@OctavianGuzu Thanks for pointing this out, I modified the comment to make it more explicit what I meant (the change introduced is wrong and needs to be modified to return the question’s name as it’s received, hence the correlation logic should be moved to interact-client)
I suspect that the error could be caused by a potential blacklisting of some letsencrypt secondary resolvers by GoDaddy, making them unable to access the exposed acme-challenge txt records. letsencrypt follows a two-step verification, the primary one using
https://unboundtest.com/
that works just fine againstinteractsh.com
(https://unboundtest.com/m/TXT/_acme-challenge.interactsh.com/ST2HYD5H)The check involves an echo mixed case. Hence the change introduced in
https://github.com/projectdiscovery/interactsh/pull/121
should be modified to return in the response the same name record from the request question field (with same uppercase/lowercase letters).interactsh-client
should handle the case-insensitive correlation. Seehttps://community.letsencrypt.org/t/certificate-verification-failure-certbot-doesnt-reach-our-dns-server-txt-records/151166
for more details. The txt validation may fail for two reasons:https://community.letsencrypt.org/t/verify-error-during-secondary-validation-fetching-timeout/134905/3
,https://community.letsencrypt.org/t/failure-during-secondary-validation-again/135194/8
andhttps://community.letsencrypt.org/t/repeated-dns-error-during-secondary-validation-dns-problem-networking-error-looking-up-a/135243/2
). The second step also fails with cert-bot with manual step-by-step verification and custom DNS server. Therefore it seems not related to interactsh.Hi @Mzack9999 ,
Sure, no worries.
I was wondering if you got it to work. “May fail randomly” implies it should work occasionally, which I couldn’t reproduce :p.
All the best!