mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
dehydrated not working on IPv6-only hosts #216
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bjacke on GitHub (Apr 20, 2017).
For some reason dehydrated tries to reach out for the issuer certificate of the intermediate cert also. As this is located on apps.identrust.com, which das no IPv6 connectivity, dehydrated throws this error
ERROR: Problem connecting to server (get for http://apps.identrust.com/roots/dstrootcax3.p7c; curl returned with 7)
and stops after that if our host has only IPv6 connectivity. Our requested certificate was already successfully issued by letsencrypt at this point.
Is there any reason why dehydrated tries to fetch this root cert? In any case a failure here should not break the processing of dehydrated here IMHO.
@lukas2511 commented on GitHub (Apr 20, 2017):
dehydrated tries to walk the chain to fetch all required intermediate certificates, it can't (reliably) detect the root certificate without fetching it first
i think the real issue here is that identrust has no ipv6 support on their hosts, but as a workaround it may be possible to allow manual specification of a certificate chain instead of querying for it
@bjacke commented on GitHub (Apr 20, 2017):
sure, this is the main problem. But as The identrust server actually doesn't need to be contacted for our certificate chain (we don't include the root cert), we could just ignore that if we run into this problem
or add an option to just fetch n certificates from the cert chain and not fetch all certs down to a root. For now (and I guess for a long time on) people with IPv6 only hosts could then simply set this value to 1 - and the problem would be solved.
@lukas2511 commented on GitHub (Apr 20, 2017):
yea, but the only way to find out if it actually is the root cert is to actually download it and check if it has a issuer certificate
no, definitively not, either full manual definition of the chain or the automatic way, but this "n certificates" sounds like it may end up with a lot of incomplete chains, which i definitively want to avoid
@bjacke commented on GitHub (Apr 20, 2017):
I don't see howa manual definition makes it any better. I will make it worse. If the intermediate changes like from X1 to X3 silently, this will not be noticed and end up in a broken chain then. The number of intermediate certs that need to be fetched will most probably not change any time soon.
@txr13 commented on GitHub (Apr 20, 2017):
Well, obviously. But that's the risk any administrator takes, any time they decide to set things to a manual process. Staying with the automatic cert-walk is a better way to go, for most people.
The number of intermediates for what CA? This script is designed to work with any ACME-compliant CA in the general case.
@lukas2511 commented on GitHub (Apr 21, 2017):
So what is different with n=whatever walks here? Like @txr13 said the chain can be completely different than Let's Encrypts current design since it's a generic ACME client, also Let's Encrypt may at any time decide to change their internal intermediate structure, which will just continue working when the chain is walked correctly, but will probably break the chain of trust for your certificate because of missing certificates.
One possibility I see would be to cache intermediate certificates by fingerprint (which iirc should already be available from the child certificate), and if it can't be fetched automatically you have the option to fill in the missing certificates yourself and it will just work on the next run.
I would probably also add a
--fix-chainscommand with that so that there is no need to run through the whole signing process again if there are any issues.@bjacke commented on GitHub (Apr 21, 2017):
I had the focus only only Letsencrypt, for generic ACME you are right, of course
not that easy any time because their intermediate certs have a basic constraint "Maximum number of intermediate CAs: 0"
Anyway, with the generic ACME in mind, just close this issue if you want, the only clean way to solve this issue is that the root CAs finally support IPv6 on their servers.
@lukas2511 commented on GitHub (Apr 21, 2017):
I'll leave this open as a reminder to implement caching of chain certificates, which would basically solve your issue with minimal manual interaction.
@asfihani commented on GitHub (Jun 4, 2017):
Hello, I have similar issue like this using CentOS 7 on Digitalocean server. Please advice the correct fix. Thanks!
@joachimtingvold commented on GitHub (Jun 25, 2017):
https://community.letsencrypt.org/t/verify-le-certificate-chain-on-ipv6-only-host-not-possible/
@shoeper commented on GitHub (Jun 25, 2017):
Link broken. Proper one is https://community.letsencrypt.org/t/obtaining-lets-encrypt-intermediates-over-ipv6-addresses/36775
@lukas2511 commented on GitHub (Jul 10, 2017):
Caching of chain certificates is now implemented. If you run into any issues you can just create the chain manually and continue using dehydrated. The core issue is of identrust only supporting legacy ip is not really related to dehydrated, so I'm closing this ticket.