Let's Encrypt auto-enable heuristic does not behave as expected
This was originally reported as a bug in #4244 (closed), where gitlab-ctl renew-le-certs
fails to renew automatically generated expired Let's Encrypt certificates. The workarounds that users found (see this and this) point to an issue in LetsEncrypt.should_auto_enable?
, the heuristic that evaluates the Let's Encrypt auto-enabled.
To resolve the bug a workaround was introduced in !3342 (merged) which also verifies the expiry of the existing Let's Encrypt certificate. However, in the process of verifying this workaround a number of concerns were raised:
- The logical structure of the
LetsEncrypt.should_auto_enable?
mandates that once theletsencrypt.auto_enabled
is set it always must evaluate totrue
. The reported bug in #4244 (closed) contradicts this which is counter-intuitive. - The root cause of the issue was not investigated. Even though we know that it can and does happen we don't why. One reason is that the logic is complicated and incorporates multiple parameters to reach to conclusion.
- The proposed workaround in !3342 (merged) has effects beyond the reported bug, namely it will overwrite the user-provided SSL certificates.
Despite the fact that the reported bug is fixed we still need to investigate how this issue can happen and how it should be addressed. Ideally we can clarify or even simplify the logic of auto-enabling Let's Encrypt integration.