mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 15:13:33 +01:00
Write certificate even if chain is not downloaded #230
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 @lukavia on GitHub (Jun 26, 2017).
I have a machine that is not allowed to make outbound connections on port 80.
443 is working fine.
As a result, when dehydrated runs, it goes through all the steps and issues the certificate, but then it tries to download the chain before saving/moving the files in place and curl fails.
Then on consequential runs, since it doesn't find the issued certificate it reissues it, but it fails again.
This leads to quickly reaching domain limit of 20 for 7 days and blocks any other subdomains for issuing new certificates.
I suggest the cert file to be written write after it is downloaded and moved in place. And then let the chain fail. That way unwanted reissuing of the certificate will be avoided
@lukas2511 commented on GitHub (Jul 10, 2017):
Mh... I've just implemented caching for certificate chains (see
d685463673), with that you could at least write the file manually and have the script working on the next run (error message gives instructions on where to get and place files).Moving the certificate in place before everything else is ready is no option for me, I (and probably most of the scripts users) always use the fullchain.pem in combination with privkey.pem, so if cert.pem and privkey.pem would have been moved in position before fullchain.pem was generated this would result in tons of broken systems.
Does the cache fix your issue? Otherwise we might think about implementing a fixup-command, that looks for unlinked certs and keys, verifies that they are valid (ocsp), generates the chain and puts them into place, but this would be quite a lot of work for an edgecase like this...
@lukavia commented on GitHub (Jul 10, 2017):
The cache would work great.
I would just install the chain with my initial & update routines.
Thank you very much :)