import-certs.sh does not use the same config.sh paths that letsencrypt.sh does. #12

New Issue

adam · 2025-12-29T00:21:45+01:00

adam commented

2025-12-29 00:21:45 +01:00

Originally created by @samueldr on GitHub (Dec 12, 2015).

As evidenced here:
d322e072d6/import-certs.sh (L14)

The actual paths checked by letsencrypt.sh:
0e92aba206/letsencrypt.sh (L29)

Originally created by @samueldr on GitHub (Dec 12, 2015). As evidenced here: https://github.com/lukas2511/letsencrypt.sh/blob/d322e072d643dcee63785be1742a56a8178f74c0/import-certs.sh#L14 The actual paths checked by letsencrypt.sh: https://github.com/lukas2511/letsencrypt.sh/blob/0e92aba206a60e00077d4b49e9479136f65587dc/letsencrypt.sh#L29

adam closed this issue

2025-12-29 00:21:45 +01:00

adam commented

2025-12-29 00:21:47 +01:00

@germeier commented on GitHub (Dec 12, 2015):

I really don't like that this is a separate script. Is there a reason this shouldn't be handeld with an "--import-certs / -i" option command in the main script?

@germeier commented on GitHub (Dec 12, 2015): I really don't like that this is a separate script. Is there a reason this shouldn't be handeld with an "--import-certs / -i" option command in the main script?

adam commented

2025-12-29 00:21:47 +01:00

@digint commented on GitHub (Dec 12, 2015):

I really don't like that this is a separate script. Is there a reason this shouldn't be handeld with an "--import-certs / -i" option command in the main script?

Please don't include helper scripts into the main script. I think the main reason why people are / will be using letsencrypt.sh is because it's simple and straightforward.

@digint commented on GitHub (Dec 12, 2015): > I really don't like that this is a separate script. Is there a reason this shouldn't be handeld with an "--import-certs / -i" option command in the main script? Please don't include helper scripts into the main script. I think the main reason why people are / will be using letsencrypt.sh is because it's simple and straightforward.

adam commented

2025-12-29 00:21:48 +01:00

@samueldr commented on GitHub (Dec 12, 2015):

I agree with digint here. Other than copying the whole configuration file searching block, I can see two ways, one really "simple" and the other not that complex that would make it find the proper config file.

Getting CONFIG_DIR from environment CONFIG_FILE="${CONFIG_FILE:-${SCRIPTDIR}/config.sh}" which is unwieldy, but would allow the configuration file to be found anywhere.
Asking the main script for the config file. The import script already know about SCRIPT_DIR, which means it know where letsencrypt.sh is. It could source the script using a particular command (--source?) which would basically "do nothing", which makes the environment available in the script that sourced it.
This approach is cleaner, but does not allow passing --config to the import script. With care, part of the letsencrypt.sh's arguments parsing could work through the sourcing, but I'm not sure how clean and how easy it would be,

@samueldr commented on GitHub (Dec 12, 2015): I agree with **digint** here. Other than copying the whole configuration file searching block, I can see two ways, one really "simple" and the other not that complex that would make it find the proper config file. 1. Getting `CONFIG_DIR` from environment `CONFIG_FILE="${CONFIG_FILE:-${SCRIPTDIR}/config.sh}"` which is unwieldy, but would allow the configuration file to be found anywhere. 2. Asking the main script for the config file. The import script already know about `SCRIPT_DIR`, which means it know where letsencrypt.sh is. It could source the script using a particular command (`--source`?) which would basically "do nothing", which makes the environment available in the script that sourced it. This approach is cleaner, but does not allow passing `--config` to the import script. With care, part of the `letsencrypt.sh`'s arguments parsing could work through the sourcing, but I'm not sure how clean and how easy it would be,

adam commented

2025-12-29 00:21:48 +01:00

@aguindehi commented on GitHub (Dec 12, 2015):

I agree with samueldr and digint. It's much cleaner to have an external helper script. Especially since that helper script will have to have multiple parts when deploying to a secondary machine (as digint did in his pull request, which I very much like). [fixed typos]

@aguindehi commented on GitHub (Dec 12, 2015): I agree with **samueldr** and **digint**. It's much cleaner to have an external helper script. Especially since that helper script will have to have multiple parts when deploying to a secondary machine (as digint did in his pull request, which I very much like). [fixed typos]

adam commented

2025-12-29 00:21:48 +01:00

@lukas2511 commented on GitHub (Dec 14, 2015):

Fixed with 1ab6a436c0 and 62037de041.

@lukas2511 commented on GitHub (Dec 14, 2015): Fixed with 1ab6a436c0c8b3588a6a398f32dcafa14560700b and 62037de04169ca36c49c581c37d0cffbce86e401.

adam referenced this issue

2025-12-29 01:28:20 +01:00

[PR #12] [MERGED] generate a new private key for each csr if the user wishes so #659

Sign in to join this conversation.