You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
DNS challenges involving CNAMEs have become thoroughly broken somewhere between version 2.15 and 2.49
To Reproduce
_acme_challenge.myserver IN CNAME 6a714c29-f980-42be-a1db-9d3450049f39.acme-challenge-responder.sargasso.net.uk.
acme-challenge-responder IN A 78.158.80.165
acme-challenge-responder IN NS acme-challenge-responder
dns_add script works correctly (verified manually) but getssl no longer recognises that it has been installed.
Debug output:
[snip]
auth_key uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA
Using dig -r CNAME _acme-challenge.mywebserver.sargasso.net.uk
Checking if CNAME result contains NS records
set primary_ns = auth1.ns.sargasso.net
set primary_ns = auth1.ns.sargasso.net
adding DNS RR via command: /home/david/Projects/getssl-scripts/dns_add_acme_dns mywebserver.sargasso.net.uk uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA
Calling https://acme-challenge-responder.sargasso.net.uk:5443 with data {"subdomain": "6a714c29-f980-42be-a1db-9d3450049f39", "txt": "uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA"}
response {"txt": "uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA"}
checking DNS at auth1.ns.sargasso.net
dig TXT _acme-challenge.mywebserver.sargasso.net.uk @auth1.ns.sargasso.net
check_result=""
expecting "uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA"
auth1.ns.sargasso.net gave ... ""
checking DNS at auth1.ns.sargasso.net for _acme-challenge.mywebserver.sargasso.net.uk. Attempt 1/100 gave wrong result, waiting 10 secs before checking again
^Cgetssl: Program interrupted by user
Traceback
main() line 3730 called
fulfill_challenges() line 1502 called
check_challenge_completion_dns() line 1 called
signal_exit() line 2741 called
error_exit() line 1328 called traceback
It is not following the CNAME and continues to query the wrong nameserver.
Manual check confirms it was in fact installed correctly:
~/.getssl$ host -t TXT _acme-challenge.mywebserver.sargasso.net.uk
_acme-challenge.mywebserver.sargasso.net.uk is an alias for 6a714c29-f980-42be-a1db-9d3450049f39.acme-challenge-responder.sargasso.net.uk.
6a714c29-f980-42be-a1db-9d3450049f39.acme-challenge-responder.sargasso.net.uk descriptive text "uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA"
6a714c29-f980-42be-a1db-9d3450049f39.acme-challenge-responder.sargasso.net.uk descriptive text "uHPdajLqVk2ELS6DNfKcpAi2iBVQ5VvwmspCXShICmA"
~/.getssl$
Expected behavior
Follow the CNAME, as Let's Encrypt themselves do (if I bypass the check it does work).
Operating system (please complete the following information):
Debian 12
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Additional context
The text was updated successfully, but these errors were encountered:
@davidc thanks for reporting this (especially the dns records which should make it easier to debug). There's a large merge request which I've not have the chance to look at around CNAMEs, so I'll look to see if that fixes the problem first!
Thanks, I did find this one https://github.com/tlhackque/getssl (#841 ) but it did not solve the issue and I stepped back in versions here until I found a working one.
FYI I don't think verification via CNAMEs was actually working in 2.15 looking at the debug output now, I think just wasn't verifying properly at all so it looked like it was working.
Describe the bug
DNS challenges involving CNAMEs have become thoroughly broken somewhere between version 2.15 and 2.49
To Reproduce
_acme_challenge.myserver IN CNAME 6a714c29-f980-42be-a1db-9d3450049f39.acme-challenge-responder.sargasso.net.uk.
acme-challenge-responder IN A 78.158.80.165
acme-challenge-responder IN NS acme-challenge-responder
dns_add script works correctly (verified manually) but getssl no longer recognises that it has been installed.
Debug output:
It is not following the CNAME and continues to query the wrong nameserver.
Manual check confirms it was in fact installed correctly:
Expected behavior
Follow the CNAME, as Let's Encrypt themselves do (if I bypass the check it does work).
Operating system (please complete the following information):
Debian 12
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Additional context
The text was updated successfully, but these errors were encountered: