Add HTTPS Protocol Support for CHALLENGE_CHECK_TYPE in getssl

[Khan-Tzar]

Currently, getssl only supports HTTP for the CHALLENGE_CHECK_TYPE option, with CHALLENGE_CHECK_TYPE="http" hardcoded as the only available setting. This configuration limits flexibility in environments where HTTPS is required for ACME challenges, particularly in situations where HTTP requests are restricted or disabled for security reasons.

Could you consider adding an option to allow CHALLENGE_CHECK_TYPE="https" in addition to the default HTTP protocol. This feature would enable verification over HTTPS, expanding getssl's versatility and compatibility in secured environments. Additionally, HTTPS support for ACME challenges aligns with modern security practices and enables environments that enforce strict HTTPS-only policies to utilize getssl without requiring workarounds.

[githubRover]

Do you mean the TLS-ALPN-01 challenge? Because the ACME API does not have an "https" one. It is not a matter of getssl supporting it. It is that Let's Encrypt must support it (and that it be an allowed method in the ACME standard).

https://letsencrypt.org/docs/challenge-types/

Discussion of different challenge types is probably best done at https://community.letsencrypt.org

But, tls-apln requires specific support in the web server (or alternate listener) to process the incoming challenge from Let's Encrypt. Apache has this in its mod_md module, for example. Various other server proxy products like caddy also have this.

In other cases, the main alternative if HTTP challenge is not acceptable is to use the DNS challenge.

[Khan-Tzar]

Then we can close the issue if this is the standard.