Add environment variable to set root CA for TLS verification

[DCsunset]

This PR adds an environment variable to set custom root CA for TLS verification. This option is safer than skipping TLS verification when using a self-signed certificate.

Furthermore, I believe it's more convenient to add a field in the config file (like TLSRootCA) that can be created during gotify init. I can continue implementing it if we agree on this idea.

[eternal-flame-AD]

Thanks for the contribution!

My thoughts

• Free CAs like LetsEncrypt are already pretty easy to configure, most people who are conscientious enough to take care of TLS would just get a regular trusted certificate.
• Go already has a built-in mechanism to override the CA store: crypto/x509#SystemCertPool:

  On Unix systems other than macOS the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively. The latter can be a colon-separated list.

• On people who are really ultra security aware and has their own CA across services, they probably would have already added their CA to the system pool instead of trying to override it in every service they host.

Suggestions

With all being said, Go does lack built-in override mechanism on Windows and MacOS which can be addressed by your fix. So I am open to merging the custom CA logic.

I think it would be also useful to implement a certificate pinning mechanism, which boils down to two features, like the SSH known_hosts file:

• An option to "pin" the expected certificate signature.
• An option to trust the server certificate on first use and remember the signature for further use.

The code structure would be about the same except provide a custom TLS verify function.

[DCsunset]

Thanks for your comment. Here are my thoughts on this:

• It's true that Let's Encrypt has already been commonly used. But when a user doesn't have a domain or they want to set up the server in a local area network with custom domain, they still need to resort to self-signed cert.
• It's actually my first time to learn that we can use SSL_CERT_FILE and SSL_CERT_DIR on most Unix systems!
• I don't think it's secure to add one's own CA to system pool. As anyone who has access to your CA can perform MITM attack on any website you visit.

As for your suggestions, I also agree it's useful to allow pinning a certificate. I'll add the option later.

[eternal-flame-AD]

@DCsunset

It's true that Let's Encrypt has already been commonly used. But when a user doesn't have a domain or they want to set up the server in a local area network with custom domain, they still need to resort to self-signed cert.

That makes sense. I agree this PR is useful in these cases. I think after the above concerns are addressed I agree this can be merged. My logic was most people in this situation would just want to pin a specific certificate instead of having their own custom CA and signing their own local domains so we should make pinning work as well aside from only allowing custom CAs. (like, I never heard anyone use a CA SSH key and sign their own machines, they just compare the fingerprint and trust)

I don't think it's secure to add one's own CA to system pool. As anyone who has access to your CA can perform MITM attack on any website you visit.

It depends on your use case, I was talking about those people who have like centralized SSL-intercepting firewalls, like a company or something.

[eternal-flame-AD]

Thanks! Looks good on my end. @jmattheis Any comments on your end?

[jmattheis]

Thanks for the contribution and the review!