TLS and HTTPS
HTTPS configuration should be explicit: own the server settings, certificate loading, and protocol floor instead of relying on folklore.
Canonical guidance
- configure HTTPS explicitly
- load certificates through a clear lifecycle
- keep TLS policy near server construction
Use when
- public HTTP services
- internal HTTPS services with managed certificates
- custom client or server TLS policy
Avoid
- copy-pasting opaque TLS settings
- mixing certificate file lookup with unrelated handler code
- assuming HTTPS is “handled somewhere else” when the service owns the listener
Preferred pattern
- construct
http.Serverandtls.Configtogether where deployment policy is visible
Anti-pattern
- enabling HTTPS with ad hoc settings no one on the team can justify
Explanation: This is tempting because security snippets get cargo-culted, but TLS policy needs ownership and context.
Why
- transport security is a runtime policy boundary, not just a call to
ListenAndServeTLS
Related pages
Sources
- crypto/tls package - Go Team
- net/http package - Go Team