-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use background DH group creation #394
Conversation
Credits to @kamermans for the idea
Might fix #396 |
local GEN_LOCKFILE="/tmp/le_companion_dhparam_generating.lock" | ||
|
||
# The hash of the pregenerated dhparam file is used to check if the pregen dhparam is already in use | ||
local PREGEN_HASH=$(md5sum "$PREGEN_DHPARAM_FILE" | cut -d ' ' -f1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why md5sum and not sha256sum ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we're just doing a quick internal file comparison and an md5 hash is more than enough for that purpose.
Worst case and extremely improbable scenario is you generate a dh params file whose md5 collide with the pre generated dh params and a new one is generated again at container restart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sha256sum
is 2 letters longer and actually safe.
Also unrelated, if I understand using this new PR means that for 1 deployment there will be 2 certificate requests right? It need to be documented so people don't go over the limits for their domain unexpectedly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is completely unrelated to certificate requests.
What this PR does is outlined in the first message:
- check if a custom (ie different from the bundled one) DH parameters file is present.
- if not, use the pre generated DH parameters file bundled with the image and start generating a new one in the background, with a low priority process.
- when the new DH parameters file is generated, reload nginx so it start using it.
The goal here was to remove the initial wait and service unavailability due to foreground DH parameters file generation (which could be quite long on some low end hardware) whilst still using a strong 2048 bits DH parameters on first start.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, I thought the DH parameter was used for the private key generation of the certificate, but it is used only in the diffie hellman.
Credits to @kamermans for most of the idea
This PR mirrors what is being done by
jwilder/nginx-proxy
: create the DH group in the background with a low priority job and use a temporary pre-generated 2048 bits DH group while it's being done. This way the container can start working immediately while still being secure.Credits goes to @kamermans for the original code contibution to
jwilder/nginx-proxy
.