addons
addons copied to clipboard
duckdns can't obtain cert after upgrade to 1.12.5
The problem
After upgrading addon to 1.12.5 version, it can't obtain certificate
Environment
- Add-on with the issue: DuckDNS
- Add-on release with the issue:
- Last working add-on release (if known):
- Operating environment (OS/Supervised): Home Assistant 2021.2.3
Problem-relevant configuration
lets_encrypt:
accept_terms: true
certfile: fullchain.pem
keyfile: privkey.pem
token: duckdns_token
domains:
- myownmane.duckdns.org
aliases:
- domain: owndomain.com
alias: myownmane.duckdns.org
seconds: 300
Traceback/Error logs
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
# INFO: Using main config file /data/workdir/config
+ Account already registered!
[15:27:13] INFO: OK
185.124.168.108
NOCHANGE
[15:27:15] INFO: Renew certificate for domains: myownmane.duckdns.org and aliases:
owndomain.com
# INFO: Using main config file /data/workdir/config
Processing owndomain.com with alternative names: myownmane.duckdns.org
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 2 authorizations URLs from the CA
+ Handling authorization for owndomain.com
+ Handling authorization for myownmane.duckdns.org
+ 2 pending challenge(s)
+ Deploying challenge tokens...
OKOK + Responding to challenge for owndomain.com authorization...
+ Cleaning challenge tokens...
OKOK + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "dns-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Incorrect TXT record \"_JSFK0dRBHcg1klisURl0aHdq1aCiZ_4imd8ZHupHhI\" found at _acme-challenge.owndomain.com",
"status": 403
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/someints/somealphas",
"token": "qNK-toen"
})
Additional information

All works great before upgrade
I have exactly the same issue. Upgraded to 1.12.5, modified the config as required by #1785, and now get the same negative result as above (Challenge is invalid). I am not sure which was the last working version. I also tried reinstalling the plugin.
If I remove the aliases, the certificate request works fine for the duckdns domain.
Same behavior here. I reconfigured DuckDNS settings following #1785 according to updated documentation, so that domains
contain only duckdns host and aliases
adds my own 3rd level domain.
I also made sure CNAME DNS record is as stated by the documentation.
As a result, I'm getting Incorrect TXT record
as well with addon unable to reissue certificate for my domain with the same message as in the issue above.
If I remember correctly, it was working before, when my domain was in both domains
and aliases
field (ie. before #1785).
Same exact issue with my setup. Didn't know about the change with #1785 so my cert expired. I updated as discussed above and got exactly the same failure.
Edit: Something fixed it. Only significant change I made is that I forwarded my 'A' record to the duckdns domain name. But I also reverted to an older version of DuckDNS (through a Snapshot) and got that working. Then I upgraded to latest and it was still able to create a cert.
I am also hitting this issue. @rruizGit what do you mean forwarding your 'A' record? Did you just create a new A record with the current IP address of your home assistant?
Alright, well I worked around this by turning off the certs in duckdns and installing the let's encrypt addon and using that to generate the certificates for me.
Sorry, crazy things going on in my life. All I did was go to my Domain/DNS host and have it point my 'A' record to the IP address of my DuckDNS IP. But truthfully, not sure if that fixed the issue or not. It could very well be that I got it to work with the previous version and then upgraded. For all I know when that cert expires the latest code could fail again. Good to know that I could always move to just using "Let's Encrypt" directly.
I am also hitting this issue. What is happening is that the addon is requesting challenges for both the alias(es) as well as the domain(s). The second challenge is overwriting the first challenge before the challenge validation is taking place, thus resulting in a failed validation.
As a temporary workaround
- Remove all the aliases from the config and let it just validate the Duckdns domains. This completes successfully.
- Put back the aliases into the config and let it re-validate all the domains. As the Duckdns domains are already validated, it will only deploy challenges to the Alias domains. This time it will complete successfully (if your alias domains point to different duckdns domains! In case more than one Alias point to the same Duckdns domain, you need to split step 2 into multiple steps and let it only validate one of the duplicate aliases at a time).
Edit: One downside of the current configuration design is that all the duckdns domains will be part of the certificate where previously I only had the domains in the Domain section as well as the Aliases on the certificate.
Same here. Since update cert cannot be renew.
Spent too much time on this.
Duck DNS addon cannot properly work with renewing cert for domain with aliases at this moment. I'm going to Duck DNS (for DDNS service) with Let's encrypt addon combo.
It is required to set auto starting Let's encrypt every day/week or so.
@sigo, do you mind sharing how you setup Let's Encrypt with aliases to get this working? I'm going through this yet again.
@rruizGit sure, but the configs isn't rocket science. I'll provide quick guide. Config details depends on DNS provider (Supported DNS providers).
Let's Encrypt documentation. It is a bit lengthy due to many supported DNS providers. Worth reading.
- Have
Duck DNS
andLet's Encrypt
plugin installed. - Have only one DNS rule -
CNAME <your-domain> -> <domain>.duckdns.org
. Can be proxied on Cloudflare. You can safely delete any other created forDuckDNS
. -
DuckDNS
config
lets_encrypt:
accept_terms: false
certfile: fullchain.pem
keyfile: privkey.pem
token: <SECRET>
domains:
- <SECRET>.duckdns.org
aliases: []
seconds: 300
-
Let's Encrypt
config mostly depends on DNS provider. I use Cloudflare with DNS challange (it doesn't require any open ports, but require Cloudflare API token withZone.DNS
permission).
email: <SECRET>
domains:
- <SECRET>
certfile: fullchain.pem
keyfile: privkey.pem
challenge: dns
dns:
provider: dns-cloudflare
cloudflare_api_token: <SECRET>
Let's Encrypt
will create temporary DNS entry for challenging while recreating certificate in this configuration.
As a bonus point, you should create some scheduled job for recreating certificate. Renew process is run only on Let's Encrypt
plugin start. Example solution.
@sigo, thank you, sir!
I am also hitting this issue. What is happening is that the addon is requesting challenges for both the alias(es) as well as the domain(s). The second challenge is overwriting the first challenge before the challenge validation is taking place, thus resulting in a failed validation.
As a temporary workaround
- Remove all the aliases from the config and let it just validate the Duckdns domains. This completes successfully.
- Put back the aliases into the config and let it re-validate all the domains. As the Duckdns domains are already validated, it will only deploy challenges to the Alias domains. This time it will complete successfully (if your alias domains point to different duckdns domains! In case more than one Alias point to the same Duckdns domain, you need to split step 2 into multiple steps and let it only validate one of the duplicate aliases at a time).
Edit: One downside of the current configuration design is that all the duckdns domains will be part of the certificate where previously I only had the domains in the Domain section as well as the Aliases on the certificate.
Thanks, this workaround works for me too. Hopefully I won’t need to do this every time though…
I found the root cause: The upgrade of the dependency dehydrated.
Since dehydrated 0.6.0, dehydrated change the domain validation strategy. Until that version, they was validation in sequential, and change to validate in parallel.
Now they, deploy all TXT for all the domains, and validate all the domains. This fails because when dehydrated starts to validate we only have the last TXT record in duckdns.org
dehydrated doesn't allow to change to the old strategy: https://github.com/dehydrated-io/dehydrated/blob/master/docs/troubleshooting.md#dns-invalid-challenge-since-dehydrated-060--why-are-dns-challenges-deployed-first-and-verified-later
Can we pin the requirement on dehydrated
to 0.5.0? I imagine there are security implications there.
Can we pin the requirement on
dehydrated
to 0.5.0? I imagine there are security implications there.
Or, if DuckDNS will never work correctly in this situation, @sigo's solution might be the way to go?
The problem is not DuckDNS, is that dehydrated now is incompatible with DuckDNS for multidomains alias. The best approach is to change from dehydrated to acme.sh:
- https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode
- https://github.com/acmesh-official/acme.sh/wiki/dnsapi#27-use-duckdnsorg-api
getssl:
- https://github.com/srvrco/getssl
Can we pin the requirement on
dehydrated
to 0.5.0? I imagine there are security implications there.Or, if DuckDNS will never work correctly in this situation, @sigo's solution might be the way to go?
My semi-manual way works, but it is workaround. It may work better (via DuckDNS). I think @marcomsousa's research is very valuable here - and it doesn't seems like "I think i know the issue".
I changed the hook.sh to print some debug information, so I'm 100% sure.
- Deploy TXT for ALIAS .dev
- Deploy TXT for DOMAIN a.duckdns.org
- Checking TXT for DOMAIN a.duckdns.org, failed becase is ALIAS .dev TXT on that system.
It's easy to change to acme.sh or getssl (removing dehydrated) and complete fix this issue.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Nope, still broken.
Same as before, removing the aliases and then adding them back temporarily resolves the issue (until the next renewal)
Any update on this issue?
I hit this problem 3 days ago. Thanks for the manual workaround, did the job for now but the issue is still not fixed...
I also have this issue
The issue still persists with DuckDNS 1.14.0
Now my certs expired and DuckDNS 1.14.0 didn't renew because of the alias, once again... It has not worked a single time. Fix from @Veldkornet doesn't work on 1.14.0. It fetches the cert after removing aliases but after adding the alias back and restarting the addon it doesn't fetch due to "Skipping renew!".
Update: Restarting home assistant resolved the issue. Even though /ssl/fullchain.pem and /ssl/privkey.pem was updated they were not applied until after restart. Old cert cached somewhere?
This add-on seems to be unmaintained. Solution from https://github.com/home-assistant/addons/issues/1869#issuecomment-902281471 could be implemented already. As alternative, someone mentioned moving to Nginx SSL addon combined with Let's Encrypt addon, I will take a look into that soon. It is missing dynamic DNS support though so probably only for those having public static IP address.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Nope Mr Bot, it's still buggered.
i can confirm the issue is still present as of today: dns-01 challenge fails if you have aliases configured right from the first start of the extension.