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