starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-11 22:30:44 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

accounts directory created in certificate directory #314

New Issue
Closed
opened 2025-12-29 01:22:24 +01:00 by adam · 3 comments
adam commented 2025-12-29 01:22:24 +01:00
Owner
Copy Link

Originally created by @txr13 on GitHub (Mar 20, 2018).

I'm not sure what caused this, honestly... but here's what happened.

This occurred using dehydrated from master, revision b116e6b, during a normal cron run. One of my certificates has a certificate-specific config file there, which specifies a different hook file. There are no other variables set in that cert-specific config.

During the cron run, I got the following output:

Processing <domain> with alternative names: <altnames>
 + Using certificate specific config file!
   + HOOK = /srv/dehydrated/hooks/dns-01-manual/cron-hook.sh
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Apr  8 23:19:24 2018 GMT (Less than 30 days). Renewing!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 6 authorizations URLs from the CA
 + Handling authorization for <domain>
 + Handling authorization for <domain>
 + Handling authorization for <domain>
 + Handling authorization for <domain>
 + Handling authorization for <domain>
 + Handling authorization for <domain>
 + 6 pending challenge(s)
 + Deploying challenge tokens...

The output for that certificate stopped there. As I had keep-going set, the run continued on to the next certificate in the list and wrapped up normally. I caught it on review of the log and didn't think much of it--I'd recently been fiddling with the hook script for that certificate, and figured I had created an error of some sort that crashed the hook.

But I also noticed today that there was a new accounts directory in the certificate output directory for that certificate, with a CA hash corresponding to the ACME v2 endpoint, with no contents. That is:

BASEDIR
|-accounts
||-ACME v1 CA hash (with account keys)
||-ACME v2 CA hash (symlink to v1 folder)
|-certs
||-domain
|||-accounts
||||-ACME v2 CA hash (no contents)
|||-cert.pem
|||-fullchain.pem
|||-etc.

I don't know how this new accounts directory got there. The time of creation matches the time when the cron job was executing. And there's zero chance my hook script was creating an accounts directory with the CA hash underneath it.

The other certificates processed at the same time do not have a local accounts folder created. It only shows up in the directory for the certificate with the per-certificate config file--which, incidentally, never returned from the deploy hook, but died quietly enough to move on to the next certificate without leaving an error in the cron log.

I'm not sure what to make of it, honestly. Any thoughts?

Originally created by @txr13 on GitHub (Mar 20, 2018). I'm not sure what caused this, honestly... but here's what happened. This occurred using `dehydrated` from master, revision b116e6b, during a normal cron run. One of my certificates has a certificate-specific config file there, which specifies a different hook file. There are no other variables set in that cert-specific config. During the cron run, I got the following output: ``` Processing <domain> with alternative names: <altnames> + Using certificate specific config file! + HOOK = /srv/dehydrated/hooks/dns-01-manual/cron-hook.sh + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Apr 8 23:19:24 2018 GMT (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 6 authorizations URLs from the CA + Handling authorization for <domain> + Handling authorization for <domain> + Handling authorization for <domain> + Handling authorization for <domain> + Handling authorization for <domain> + Handling authorization for <domain> + 6 pending challenge(s) + Deploying challenge tokens... ``` The output for that certificate stopped there. As I had keep-going set, the run continued on to the next certificate in the list and wrapped up normally. I caught it on review of the log and didn't think much of it--I'd recently been fiddling with the hook script for that certificate, and figured I had created an error of some sort that crashed the hook. But I also noticed today that there was a new `accounts` directory in the certificate output directory for that certificate, with a CA hash corresponding to the ACME v2 endpoint, with no contents. That is: ``` BASEDIR |-accounts ||-ACME v1 CA hash (with account keys) ||-ACME v2 CA hash (symlink to v1 folder) |-certs ||-domain |||-accounts ||||-ACME v2 CA hash (no contents) |||-cert.pem |||-fullchain.pem |||-etc. ``` I don't know how this new `accounts` directory got there. The time of creation matches the time when the cron job was executing. And there's zero chance my hook script was creating an accounts directory with the CA hash underneath it. The other certificates processed at the same time do not have a local `accounts` folder created. It only shows up in the directory for the certificate with the per-certificate config file--which, incidentally, never returned from the deploy hook, but died quietly enough to move on to the next certificate without leaving an error in the cron log. I'm not sure what to make of it, honestly. Any thoughts?
adam closed this issue 2025-12-29 01:22:24 +01:00
adam commented 2025-12-29 01:22:25 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Mar 24, 2018):

Mhm, do you have a config file in that certificate directory and is there the slightest possibility that dehydrated was somehow executed inside of that directory?

accounts gets appended to BASEDIR, which normally comes from the config location, which (if there is nothing in /etc/dehydrated and /usr/local/etc/dehydrated) will be the current working directory

But if that happened it shouldn't have continued as it would basically have used a broken config and/or an empty accounts directory... but there is no other way, the word accounts doesn't occur anywhere else in the script and ACCOUNTDIR is only really used in the beginning of the script...

@lukas2511 commented on GitHub (Mar 24, 2018): Mhm, do you have a config file in that certificate directory and is there the slightest possibility that dehydrated was somehow executed inside of that directory? `accounts` gets appended to `BASEDIR`, which normally comes from the config location, which (if there is nothing in `/etc/dehydrated` and `/usr/local/etc/dehydrated`) will be the current working directory But if that happened it shouldn't have continued as it would basically have used a broken config and/or an empty `accounts` directory... but there is no other way, the word `accounts` doesn't occur anywhere else in the script and `ACCOUNTDIR` is only really used in the beginning of the script...
adam commented 2025-12-29 01:22:26 +01:00
Author
Owner
Copy Link

@txr13 commented on GitHub (Mar 24, 2018):

The command as written in cron is:

/srv/dehydrated/dehydrated —cron —keep-going

Main config file is located at /srv/dehydrated/config. The certificate-specific config file is located within the certificate directory, but does not override the value of BASEDIR (which is set within the main config file).

I know, it’s weird.

@txr13 commented on GitHub (Mar 24, 2018): The command as written in cron is: /srv/dehydrated/dehydrated —cron —keep-going Main config file is located at /srv/dehydrated/config. The certificate-specific config file is located within the certificate directory, but does not override the value of BASEDIR (which is set within the main config file). I know, it’s weird.
adam commented 2025-12-29 01:22:26 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Apr 8, 2018):

I'm closing this for now as I can't reproduce this other than by running dehydrated directly in a certificate directory (any possibility that your hook-script somehow ran dehydrated?).

I might change the (preferred) name for that config file in the future so dehydrated doesn't ever get confused by this...

@lukas2511 commented on GitHub (Apr 8, 2018): I'm closing this for now as I can't reproduce this other than by running dehydrated directly in a certificate directory (any possibility that your hook-script somehow ran dehydrated?). I might change the (preferred) name for that config file in the future so dehydrated doesn't ever get confused by this...
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#314
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?