[GH-ISSUE #28] Automatic SSL/TLS #27

New issue

Closed

opened 2026-03-15 12:09:44 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 12:09:44 +03:00

Owner

Originally created by @jimafisk on GitHub (Dec 20, 2022).
Original GitHub issue: https://github.com/axllent/mailpit/issues/28

I saw the docs about pointing to an existing SSL/TLS certificate: https://github.com/axllent/mailpit/wiki/HTTPS

Another Go project, PocketBase, automatically issues Let's Encrypt certs if you pass the --https flag: ./pocketbase serve --http="mysite.com:80" --https="mysite.com:443"

It looks like they use https://pkg.go.dev/golang.org/x/crypto/acme/autocert

Here's how it is implemented in their server code: https://github.com/pocketbase/pocketbase/blob/master/cmd/serve.go#L61

Would something like that align with the roadmap for Mailpit? It's an awesome project by the way, thanks for all your hard work!

Originally created by @jimafisk on GitHub (Dec 20, 2022). Original GitHub issue: https://github.com/axllent/mailpit/issues/28 I saw the docs about pointing to an existing SSL/TLS certificate: https://github.com/axllent/mailpit/wiki/HTTPS Another Go project, [PocketBase](https://pocketbase.io/), automatically issues [Let's Encrypt](https://letsencrypt.org/) certs if you pass the `--https` flag: `./pocketbase serve --http="mysite.com:80" --https="mysite.com:443"` It looks like they use https://pkg.go.dev/golang.org/x/crypto/acme/autocert Here's how it is implemented in their server code: https://github.com/pocketbase/pocketbase/blob/master/cmd/serve.go#L61 Would something like that align with the roadmap for Mailpit? It's an awesome project by the way, thanks for all your hard work!

kerem closed this issue

2026-03-15 12:09:49 +03:00

kerem commented

2026-03-15 12:09:55 +03:00

Author

Owner

@axllent commented on GitHub (Dec 21, 2022):

Thanks for the kind words @jimafisk.

Early on in development I had briefly considered something like this, however I very quickly came to the conclusion that it would cause far more problems than it would solve. Firstly Mailpit is designed to run as a separate stand-alone service, mostly alongside whatever other services there would be. In most cases this means that a webserver is already running on ports 80 & potentially 443, and that Mailpit is running on some alternate port (eg 8025). In order for Let's Encrypt to register or renew, the certificate requesting service must be running unencrypted on port 80 (even if it's a redirect to another secure port), and must be accessible to the internet on those ports. This is by design of Let's Encrypt.

This would mean that Mailpit would need to run an unencrypted HTTP server on port 80, and redirect to whatever other port one has chosen. So to get back to my point - users who would try make use of such a feature would end up with all sorts of conflicts because of the requirement for port 80 (conflicting with existing services) or they wouldn't realize that it has to be externally accessible, and I would endlessly have to explain that this functionality would be for edge cases whereby Mailpit would be running as the only service on an externally-accessible port 80 etc etc.

It's just not worth the effort to be honest. If the hosting server doesn't already run anything on port 80 (but is accessibly from the internet), then Certbot has ways to spin up a temporary HTTP server to handle the certificate request. So basically there are already existing official tools to handle this, rather than try and cater for everyone's unique situations using software that is "is a work in progress and makes no API stability promises".

I hope that makes sense, but this is not a viable option for Mailpit.

@axllent commented on GitHub (Dec 21, 2022): Thanks for the kind words @jimafisk. Early on in development I had briefly considered something like this, however I very quickly came to the conclusion that it would cause far more problems than it would solve. Firstly Mailpit is designed to run as a separate stand-alone service, mostly alongside whatever other services there would be. In most cases this means that a webserver is already running on ports 80 & potentially 443, and that Mailpit is running on some alternate port (eg 8025). In order for Let's Encrypt to register or renew, the certificate requesting service must be running unencrypted on port 80 (even if it's a redirect to another secure port), and must be accessible to the internet on those ports. This is by design of Let's Encrypt. This would mean that Mailpit would need to run an unencrypted HTTP server on port 80, and redirect to whatever other port one has chosen. So to get back to my point - users who would try make use of such a feature would end up with all sorts of conflicts because of the requirement for port 80 (conflicting with existing services) or they wouldn't realize that it has to be externally accessible, and I would endlessly have to explain that this functionality would be for edge cases whereby Mailpit would be running as the only service on an externally-accessible port 80 etc etc. It's just not worth the effort to be honest. If the hosting server doesn't already run anything on port 80 (but is accessibly from the internet), then Certbot has ways to spin up a temporary HTTP server to handle the certificate request. So basically there are already existing official tools to handle this, rather than try and cater for everyone's unique situations using software that is "is a work in progress and makes no API stability promises". I hope that makes sense, but this is not a viable option for Mailpit.

kerem commented

2026-03-15 12:10:00 +03:00

Author

Owner

@jimafisk commented on GitHub (Dec 21, 2022):

Totally understand, thanks for the explanation!

@jimafisk commented on GitHub (Dec 21, 2022): Totally understand, thanks for the explanation!