Write certificate even if chain is not downloaded #230

Closed
opened 2025-12-29 01:19:26 +01:00 by adam · 2 comments
Owner

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

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
adam closed this issue 2025-12-29 01:19:26 +01:00
Author
Owner

@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...

@lukas2511 commented on GitHub (Jul 10, 2017): Mh... I've just implemented caching for certificate chains (see d685463673919ba4f9d2035d021293f241a66055), 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...
Author
Owner

@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 :)

@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 :)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#230