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 the
letsencrypt.auto_enabledis set it always must evaluate to
true. 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.