Add proxy support and optional email

[aleskxyz]

Summary

• Add configurable proxy support so Certbot traffic can be routed through SOCKS/HTTP proxies using proxychains4.
• Make CERTBOT_EMAIL optional while still allowing non-interactive operation.
• Document the new behavior and configuration options in the README.

Changes

• Introduced new environment variables:
  • PROXY_TYPE (supported: none, socks5, socks4, http, https)
  • PROXY_HOST
  • PROXY_PORT
  • PROXY_USERNAME
  • PROXY_PASSWORD
• Updated entrypoint.sh to:
  • Validate PROXY_TYPE and require PROXY_HOST / PROXY_PORT when a proxy is enabled.
  • Generate /etc/proxychains/proxychains.conf from the proxy env vars (including optional auth).
  • Automatically wrap the Certbot command with proxychains4 when PROXY_TYPE != none.
• Adjusted Certbot invocation:
  • If CERTBOT_EMAIL is set, pass --email $CERTBOT_EMAIL.
  • If CERTBOT_EMAIL is empty, use --register-unsafely-without-email to keep it non-interactive.
• Updated README.md:
  • Marked CERTBOT_EMAIL as optional and documented the fallback behavior.
  • Added descriptions for the new proxy-related environment variables and valid proxy types.

Notes

• Default behavior (no proxy, email provided) remains unchanged.
• When a proxy is configured, all Certbot ACME traffic is routed through the configured proxy via proxychains4.

[aleskxyz]

Hi @jaydrogers
Can you please review and merge this PR?
Thanks

[Rithari]

I know that LetsEncrypt stopped sending emails about the renewal, but does that make the email parameter redundant or are there other types of emails they send?
If the fallback is "unsafely registering" (as per the parameter name), is it really a good idea to not enforce the e-mail in any case for this implementation?

I understand however that at the end of the day, this should wrap around the supported options that LetsEncrypt themselves support, so my feedback might be irrelevant in this case.

The proxy implementation looks OK to me.

[aleskxyz]

I know that LetsEncrypt stopped sending emails about the renewal, but does that make the email parameter redundant or are there other types of emails they send?
If the fallback is "unsafely registering" (as per the parameter name), is it really a good idea to not enforce the e-mail in any case for this implementation?

I understand however that at the end of the day, this should wrap around the supported options that LetsEncrypt themselves support, so my feedback might be irrelevant in this case.

The proxy implementation looks OK to me.

Hi,
I changed the email address to optional because when I use this Docker image in some automation tasks, I had to request the user’s email, even though it wasn’t really necessary. I made it optional so we can maintain backward compatibility.
Thanks

[jaydrogers]

Hi @aleskxyz — thanks for the PR! Both features are great ideas. I pushed a commit to your branch that keeps your email change and reworks the proxy support. Here's the summary of the changes:

Proxy support → standard env vars

Certbot (requests) and the Cloudflare SDK (httpx) both natively honor HTTP_PROXY/HTTPS_PROXY/NO_PROXY (requests docs, httpx docs). Certbot doesn't document this itself but I had Fable 5 assist in the research and verified it with a few tests. Instead of proxychains, the image now just installs the two SOCKS backends (pysocks + socksio). The documentation has been updated to reflect the new approach:

environment:
  HTTPS_PROXY: "socks5h://user:pass@proxy.example.com:1080"  # or http://proxy:3128

Why the change:

• Standard convention. No custom PROXY_* vars, works like every other tool
• No proxy password written to disk (proxychains config was world-readable)
• ~65 fewer lines of entrypoint shell, no LD_PRELOAD
• Avoids a runtime bug: PROXY_TYPE=https isn't a valid proxychains-ng type (only http/socks4/socks5/raw)

Verified on the built image: proxy routing confirmed for both ACME and Cloudflare API traffic, socks5:///socks5h:// accepted by both stacks, and env vars survive the PUID/PGID privilege drop (su-exec passes environment through).

Set emails as optional for Let's Encrypt

This feature is kept, but I made a few small changes:

• Now uses the entrypoint's existing set -- "$@" pattern instead of unquoted string expansion
• Startup banner shows 📧 Email: (none — registering without an email address) so the fallback is never silent

Regarding the question from @Rithari:

I know that LetsEncrypt stopped sending emails about the renewal, but does that make the email parameter redundant or are there other types of emails they send? If the fallback is "unsafely registering" (as per the parameter name), is it really a good idea to not enforce the e-mail in any case for this implementation?

Since Let's Encrypt stopped sending expiration emails (June 2025), email-less registration loses nothing. Certbot itself removed its warnings about empty email for exactly this reason (certbot#10214). The tests I ran were against the Let's Encrypt staging server and it came back with: Account registered.

Next Steps

@aleskxyz: Can you test the updated branch against your real proxy? You have the actual environment that motivated this proposal. Once confirmed, I'm happy to merge. 🚀