infinityofspace / certbot_dns_porkbun

Plugin for certbot to obtain certificates using a DNS TXT record for Porkbun domains
MIT License
56 stars 8 forks source link

Subdomains (incl. wildcards) Cannot be Processed #49

Closed ghost closed 2 years ago

ghost commented 2 years ago

Describe the bug The use of -d "domain.tld" works as expected but -d "*.domain.tld" or -d "sub.domain.tld" results in a failed cert generation

To Reproduce use -d "*.domain.tld" or -d "sub.domain.tld"

Expected behavior Cert should be processed as expected

Certbot command certbot certonly --non-interactive --agree-tos --email person@email.com --preferred-challenges dns --authenticator dns-porkbun --dns-porkbun-credentials /config/porkbun.ini --dns-porkbun-propagation-seconds 60 -d "*.domain.tld"

Versions (please complete the following version information):

Error message

Encountered exception during recovery: KeyError: 'LONG_RANDOM_ISH_KEY_HERE'

ERROR: DNS create api call was not successfully

Status code: 400

Additional context client.py potentially removed the "*." replacement:

infinityofspace commented 2 years ago

Thank you for the bug report.

Unfortunately, I cannot reproduce the error described. All types of cert domains *.domain.tld, domain.tld, sub.domain.tld, sub2.sub1.domain.tld works fine for me.

The error message indicates that the API call to Porkbun was not successful. The http status code 400 describes an issue with the request (Bad Request) and the error message Encountered exception during recovery: KeyError: 'LONG_RANDOM_ISH_KEY_HERE' means the cleanup of the failed challenge failed because there was no TXT record created with the id of the long random key value (the long random value is the public secret of the DNS challenge). So the KeyError error can be ignored, since this is a consecutive error due to the failed Porkbun API call.

There should also be a more detailed error message (or no message found for an unknown error message) below the Status code: 400. Can you please share this message as well (you should replace private information with placeholder like you did with the domain)?

There are two possible causes of failure that I can mention without further information:

  1. there is a typo in the domain name (is rather unlikely, but please check the correct spelling)
  2. you have a DNS record which delegates the original domain to a non Porkbun managed domain, eg. _acme-challenge.domain.tld. 600 IN CNAME _acme-challenge.domain2.tld.

The DNS delegation feature was introduced in version v0.3, to eliminate a general problem with it you could try the version v0.2.1.


client.py potentially removed the "*." replacement:

It is true that client.py removes the wildcard, but this is an intentional behavior. Specifying the domain with a wildcard *.domain.tld or without domain.tld is only relevant for cerbot and not for the Porkbun API call, since when we create the challenge for both of the specified domain, they both have to result in a TXT record for the subdomain _acme-challenge.domain.tld. So we have to remove the wildcard symbol. However, this behavior is logically different for certificates for subdomains and here the subdomains are taken into account accordingly. So a cert for the domain sub2.sub1.domain.tld result in a TXT record for the domain _acme-challenge.sub2.sub1.domain.tld. Because of the described resulting TXT entries your described error for wildcard domains and no error without the wildcard is very strange and if one of the two fails, then both should fail.

ghost commented 2 years ago

Thanks for the in depth reply! Through some discussions I wiped prior _acme-challenge.domain.tld entries and recreated my command only to notice I included an incorrect credential format within /config/porkbun.ini:

dns_porkbun_key=porkbunapikey dns_porkbun_secret=porkbunapikeysecret

versus

dns_porkbun_key porkbunapikey dns_porkbun_secret porkbunapikeysecret

Through several different testing configurations today each returned an as expected result.