Golang如何为Web应用设置SSL/TLS安全连接_技术教程

最直接方式是用 http.ListenAndServeTLS(":443", "fullchain.pem", "privkey.pem", nil)，需 PEM 格式且私钥未加密；更灵活则用 http.Server 配 TLSConfig，支持协议限制、密码套件控制及客户端证书验证。

用 `http.ListenAndServeTLS` 启动 HTTPS 服务最直接

Go 标准库不依赖外部 TLS 终止代理，可原生支持 HTTPS。核心是调用 http.ListenAndServeTLS，它比 http.ListenAndServe 多两个参数：certFile 和 keyFile。

这两个文件必须是 PEM 格式，且私钥不能加密（即不能带密码保护），否则会报错 tls: failed to find any PEM data in certificate input 或 x509: decryption password required。

certFile 通常为 fullchain.pem（含证书 + 中间证书），不是单独的 domain.crt
keyFile 应为未加密的 privkey.pem；若已加密，可用 openssl rsa -in key.pem -out key-unencrypted.pem 去密
端口必须显式设为 443（或其它 HTTPS 常用端口），不能省略；":https" 这类写法无效

package main

import (
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello over HTTPS"))
    })
    log.Fatal(http.ListenAndServeTLS(":443", "fullchain.pem", "privkey.pem", nil))
}

用 `http.Server` 手动配置 TLS 更灵活

当需要自定义 TLS 行为（如限制协议版本、禁用弱密码套件、启用客户端证书验证）时，应构造 http.Server 实例并设置 TLSConfig。

常见需求包括：

禁用 TLS 1.0/1.1：设置 MinVersion: tls.VersionTLS12
强制使用现代加密套件：通过 CipherSuites 显式指定（注意顺序，优先级从左到右）
启用 HTTP/2：Go 1.8+ 默认开启，但要求 TLSConfig.NextProtos 包含 "h2"（http.Server 默认已配好，一般不用改）
验证客户端证书：设置 ClientAuth: tls.RequireAndVerifyClientCert 并加载 CA 证书到 ClientCAs

srv := &http.Server{
    Addr: ":443",
    Handler: myHandler,
    TLSConfig: &tls.Config{
        MinVersion: tls.VersionTLS12,
        CipherSuites: []uint16{
            tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
            tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
        },
    },
}
log.Fatal(srv.ListenAndServeTLS("fullchain.pem", "privkey.pem"))

本地开发用 `crypto/tls` 生成自签名证书

生产环境必须用可信 CA（如 Let’s Encrypt）签发的证书；但开发时可快速生成自签名证书，避免每次改域名都申请。

Go 自带 crypto/tls 提供了 GenerateKeyPair 的能力，但更推荐用命令行工具（如 mkcert）——它生成的证书会被本地系统信任，浏览器不会报 NET::ERR_CERT_AUTHORITY_INVALID。

用 mkcert -install && mkcert example.com 生成 example.com.pem 和 example.com-key.pem
若坚持用 Go 代码生成，注意：必须将生成的 *x509.Certificate 和 priv *ecdsa.PrivateKey 分别写入 PEM 文件，且私钥需用 pem.Encode 写入 "EC PRIVATE KEY" 类型块（不是 "PRIVATE KEY"），否则 ListenAndServeTLS 会解析失败
自签名证书的 Subject.CommonName 或 DNSNames 必须匹配请求域名，否则浏览器提示 ERR_CERT_COMMON_NAME_INVALID

Let’s Encrypt 自动续期要绕开 Go 的阻塞式 `ListenAndServeTLS`

http.ListenAndServeTLS 是阻塞调用，无法在运行中热更新证书；而 Let’s Encrypt 证书 90 天过期，必须自动续期。

可行方案是：用 autocert 包（官方维护）配合 http.Server，它会在首次请求时自动申请并缓存证书，后续自动续期。

必须暴露 HTTP 端口（通常是 :80）用于 ACME HTTP-01 挑战，即使你只提供 HTTPS 服务
缓存目录（如 "./certs"）必须可读写，且需持久化，否则每次重启都重新申请
不建议在生产环境直接用 autocert.Manager.HTTPPort = "80"；应由反向代理（如 Nginx）处理挑战，Go 应用只管 HTTPS 流量
若必须纯 Go 方案，autocert 支持 DNS-01（需实现 Provider 接口），但复杂度陡增

mgr := &autocert.Manager{
    Prompt:     autocert.AcceptTOS,
    HostPolicy: autocert.HostWhitelist("example.com"),
    Cache:      autocert.DirCache("./certs"),
}
srv := &http.Server{
    Addr: ":443",
    Handler: myHandler,
    TLSConfig: &tls.Config{
        GetCertificate: mgr.GetCertificate,
    },
}
log.Fatal(srv.ListenAndServeTLS("", "")) // cert/key 为空，由 mgr 动态提供

证书路径错误、私钥加密、协议版本过低、ACME 挑战端口被占——这些问题在线上环境往往表现为静默失败或连接重置，而不是清晰报错。调试时优先检查 ListenAndServeTLS 返回的 error，再确认证书 PEM 块类型和域名匹配性。