Allow HTTPS only, and separate Autocert from it

[nanohard]

In a live production. HTTPS is not working, get a 502 error. There is no error output on the console. I already have a cert for the domain. How can I use the cert I already have with ponzu?

Have also tried under a subdomain, and listed that in /admin/init. I think it isn't fetching the cert, and still get a 502 error.

[nanohard]

I managed to edit enable.go and main.go to serve only TLS and not use the autocert bot.

[nilslice]

I appreciate you asking all these questions, and if you have found solutions it would be equally appreciated by myself and the community if you'd share.

It's obviously not a requirement, but many people solved problems and did work that you no longer need to do; it's kind to repay that with other shared solutions.

Feel free to submit a PR with a patch or at the very least some more detail on your problem & solution would be great.

👍

[nanohard]

Something like disabling the autocert would be more of a fork... unless the autocert could be used only if --autocert were an option... I'll look into it. This shouldn't be too hard.

[nanohard]

• Add --autocert to list of flags. It will invoke tls.Enable()
• Create function to serve TLS only. This means changing main.go so HTTP does not start on its own, which means adding a flag for it. Also don't use tls.Enable() unless --autocert is called; so ListenAndServeTLS() will need its own function. Everything needs to be separate; 3 functions/flags: --autocert, --https, --http
  • Just run --autocert by itself the first time to get the cert. Afterwards, it is not needed.
• Need a config file for paths of fullchain.pem and privkey.pem.

[nanohard]

Certificate file path will be hardcoded: "/etc/letsencrypt/live/"+db.Config("domain")+"/fullchain.pem" and /privkey.pem as the location.

[nilslice]

What are your thoughts colocating the certs and the rest of the ponzu deployment? (similar to how the db files are next to the binary).

My thinking is that the path you have hardcoded wouldn't be an obvious location on a windows server, so there would need to either be a check for the current running operating system and then determine a location (less ideal), or keep the certs next to the ponzu-server binary?

[nanohard]

Hmm... Well, we could:

• add a flag for --cert and --key paths
• colocate, and admin would have to make sure to place files in that dir (or symlink)

I forgot to think about certs that people buy, or get for free for one year when they sign up for a hosting service. So I feel like we can set a default dir of /etc/letsencrypt and have flags to set a different path, or colocate. I don't see any other options off the top of my head.

[nilslice]

The --cert and --key paths make a lot of sense to me, but I think we should consider leaving the default path as-is: https://github.com/ponzu-cms/ponzu/blob/master/system/tls/enable.go#L27, since it is fairly generic enough to support other certs if someone wanted to just throw them in there, plus doesn't muck with the OS paths (and doesn't care which kind of OS we're installed on). I'm not sure what the file names are for the files downloaded from Let's Encrypt, but those should be the defaults.

This way, if the key/cert flags aren't set, any certs placed in the default location & named properly will still work (even if they are not from Let's Encrypt), so long as the key/cert flag values are used here https://github.com/ponzu-cms/ponzu/blob/master/system/tls/enable.go#L81.

I believe the tls package also needs to be aware of these paths, since the invocation of ponzu-server run should still require --https to start the TLS server, thus calling tls.Enable(), but the Enable func would need to change to observe the key/cert flags, and if they are set, use them as the directory cache for the manager. We should allow users to set another flag (e.g. bool --managed-tlsor something) if they intend to manage their own certificates. Doing so would tell Enable() to skip the manager code and the goroutine to handle the ACME challenge.

What do you think?

[nanohard]

I like the way you think. Agreed; if --cert and --key paths are not set, then the default path will be used. As it stands, I created a separate function and renamed the current function for Autocert: tls.EnableAutoCert() tls.EnableHTTPS()

EnableAutoCert has otherwise not been touched. The reason for making a separate function here is to allow for easy readability and easy function calls from main.go

[logicalphase]

I think setting paths would be particularly helpful in dev environment too where we use our own localhost CA root. Be nice to only need to symlink to one location for Ponzu and front end builds like Polymer, and other platforms, etc.