[Feature] fallback to HTTP-01 Challenge when of using TLS-ALPN-01 Challenge when attempting SSL

[RetributionByRevenue]

In a scenario where you are trying to renew a new certificate or failing the TLS-ALPN-01 challenge for the first time (human error in config, networking in docker container non-standard, etc), it would be nice and advantageous in production environments fall back on HTTP-01 Challenge.

my conversation with chatgpt:	Characteristic	HTTP-01 Challenge	TLS-ALPN-01 Challenge
Communication	HTTP request to a well-known URL (.well-known/acme-challenge/)	Direct TLS connection using ALPN negotiation
Port Requirement	Requires port 80 (HTTP) to be open	Requires port 443 (HTTPS) to be open
Protocol	Uses the HTTP protocol	Uses TLS handshake via ALPN (TLS layer)
Web Server	Typically uses a web server (e.g., Nginx, Apache, or Certbot’s temporary server)	Does not require an HTTP web server (only TLS)
Self-Signed Cert	Not needed	Requires a special self-signed cert with the token
Use Case	Common for general web servers	Useful when port 80 is unavailable or HTTPS-only environments

TLS-ALPN-01 challenge is different from the HTTP-01 challenge in the way it verifies domain ownership. While both challenges are part of the ACME (Automatic Certificate Management Environment) protocol, they work in distinct ways:

1. HTTP-01 Challenge (Used in the standalone method you ran) How It Works: Certbot sets up a temporary HTTP server (on port 80) to serve a specific token at a well-known URL path (e.g., http://example.com/.well-known/acme-challenge/XYZ). The Certificate Authority (CA) sends an HTTP request to your domain, retrieves the token, and verifies it matches what it expects. Port Requirement: The challenge requires port 80 (HTTP) to be accessible and free on the server. Use Case: This is the most commonly used challenge, especially for websites that use HTTP/HTTPS traffic.
2. TLS-ALPN-01 Challenge How It Works: The TLS-ALPN-01 challenge uses the Application-Layer Protocol Negotiation (ALPN) extension of TLS. Instead of creating an HTTP request, the CA connects directly to your server over port 443 (the HTTPS port) and attempts to negotiate a TLS handshake with a special ALPN protocol (acme-tls/1).

---

I'm a big fan. this project saved my ass and surprisingly works on an old Alpine linux server.

[RetributionByRevenue]

for example something like in the config would be a pretty intuitive way to do this i think:

# Global ACME settings. Unless specified, ACME is disabled.
[experimental.acme]
dir_url = "https://localhost:14000/dir" # optional. default is "https://acme-v02.api.letsencrypt.org/directory"
enable_http-challenge_falback = true
email = "test@example.com"
registry_path = "./acme_registry"     

because the create you are already using supports this type of challenge already

[junkurihara]

Hi @RetributionByRevenue

Sorry for my delayed reply. Thank you for your proposal and relevant information.

I think falling back to HTTP-01 sounds maybe reasonable, I did never faced such a situation although. Honestly I did not get convinced that TLS-ALPN-01 is insufficient and rpxy should handle a kind of misconfiguration of docker.

I also think that it is a bit tricky to be integrated with the current mechanism. So we should carefully consider how the internal component of rpxy should be if we decide to append this brand-new feature that might be a braking change.