如何在NGINX上安装SSL证书

本指南将向您展示如何在 NGINX 上安装 SSL/TLS 证书。内容涵盖了大多数人容易出错的部分：构建 NGINX 所需的正确证书链（”fullchain”）、将正确的指令指向正确的文件、在重新加载之前测试配置，以及添加一个干净的 HTTP 到 HTTPS 重定向，确保每位访客都能进入您网站的安全版本。

为 NGINX 生成 CSR 代码

如果您已经生成了 CSR 并手头持有已签发的证书文件，可以直接跳到在 NGINX 上安装 SSL 证书部分。

在证书颁发机构签发证书之前，您需要提交一份 CSR（证书签名请求）：一段包含您域名信息和公钥的小型文本块，与保存在服务器上的私钥配对。您有两种选择：

• 使用我们的CSR 生成器自动生成 CSR。该工具会同时返回 CSR 和匹配的私钥，随后您可将其上传到服务器。
• 按照我们的教程如何在 NGINX 上生成 CSR，使用 OpenSSL 在服务器本身上生成 CSR。私钥将保留在服务器上。

用任意文本编辑器打开生成的 .csr 文件；其中的文本块（包括 —–BEGIN CERTIFICATE REQUEST—– 和 —–END CERTIFICATE REQUEST—– 这两行）就是您在结账时粘贴到 SSL 申请表单中的内容。如果想在提交前确认 CSR 的内容，可以将其粘贴到我们的CSR 解码器中。

在 NGINX 上安装 SSL 证书

一旦 CA 签发了证书，您通常会收到以下内容：

• 您的主（服务器）证书，通常是以您的域名命名的 .crt 文件。
• 中间证书（有时还包括根证书），可能是单独的 .crt 文件，也可能打包在一个 .ca-bundle 文件中。
• 与您的 CSR 一起生成的私钥（一个 .key 文件）。

NGINX 需要将服务器证书和中间证书链合并为一个文件（即 “fullchain”），并通过 ssl_certificate 指向该文件；私钥则通过 ssl_certificate_key 单独指向。跳过证书链是最常见的安装错误：证书在桌面浏览器中看起来没有问题，但在 Android、API 客户端以及像我们的 SSL Checker 这样的工具中却会失败。

步骤 1：将证书合并为一个文件

合并文件中证书的顺序很重要。您的服务器证书排在最前面，然后是从签发叶证书的 CA 向上的每个中间证书，根证书排在最后（或省略，因为浏览器已经信任其内置存储中的根证书）：

• 您域名的主证书。
• 中间证书。
• 根证书（可选）。

您可以在文本编辑器中手动构建 fullchain 文件（按顺序粘贴每个 PEM 块），也可以通过一条 cat 命令完成。如果您收到的是单独的中间证书和根证书文件，请运行：

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

如果中间证书和根证书已经合并在一个 .ca-bundle 文件中，请运行：

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

将文件名替换为您自己的文件名。将合并后的文件（以及私钥，如果尚未存在于该目录）移动到服务器上的 SSL 目录，例如 /etc/ssl/ 或 /etc/nginx/ssl/。确保密钥文件只能由 root 读取：

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

步骤 2：编辑 NGINX 配置文件

打开您网站的 NGINX 配置文件。在 Debian 和 Ubuntu 上，该文件位于 /etc/nginx/sites-available/（并在 sites-enabled/ 中有一个符号链接）；在 RHEL、CentOS、AlmaLinux 和 Rocky Linux 上，则位于 /etc/nginx/conf.d/。添加或编辑监听 443 端口的 server 块，使其指向 fullchain 文件和私钥：

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

关于上述指令，有几点说明：

• listen 443 ssl; 在 443 端口上启用 TLS。旧版的 ssl on; 指令已在 NGINX 1.25 中被移除，不应出现在现代配置中。
• http2 on; 作为独立指令启用 HTTP/2（NGINX 1.25.1 及更高版本）。旧版配置使用 listen 443 ssl http2;，虽然仍可正常工作，但已被弃用。
• ssl_protocols TLSv1.2 TLSv1.3; 禁用了过时的 TLS 1.0 和 1.1。从 NGINX 1.27.3 起，即使省略该指令，这也是默认设置，但显式设置是更清晰、更便于审计的做法。
• 该密码套件列表与 Mozilla 的 “intermediate” 配置文件相匹配，可在所有较新的客户端上正常工作。如果您只需要支持 TLS 1.3 的客户端，可以完全省略 ssl_ciphers。

步骤 3：将 HTTP 重定向到 HTTPS

在 80 端口添加一个单独的 server 块，将所有请求永久重定向到 HTTPS，这样通过普通 HTTP 访问的访客也会进入安全网址：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

使用 return 301 比基于正则表达式的 rewrite 规则更快、更安全，也是 NGINX 官方推荐的做法。

步骤 4：测试配置并重新加载 NGINX

在重新加载之前，请务必先验证配置，以免拼写错误导致服务下线：

sudo nginx -t

您应该会看到 syntax is ok 和 test is successful。如果报告了错误，消息中会包含文件名和行号；修正后请再次运行测试。测试通过后，重新加载 NGINX，使其应用新配置而不中断现有连接：

sudo systemctl reload nginx

在没有 systemd 的系统上，请改用 NGINX 自身的重新加载信号：

sudo nginx -s reload

请优先使用 reload 而非 restart：reload 会在不关闭现有连接的情况下重新读取配置，而 restart 会中断这些连接。

步骤 5（可选）：启用 OCSP 装订

OCSP 装订让 NGINX 在证书旁附带一份最新的、经过签名的吊销状态信息，这样客户端就无需在每次握手时都联系 CA。请在您的 HTTPS server 块中添加以下内容：

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

再次使用 sudo systemctl reload nginx 重新加载 NGINX。装订是一项虽小但很值得实施的加固措施，大多数现代证书都默认支持它。

验证安装

在浏览器中通过 https:// 打开您的网站，检查锁形图标是否已关闭，且证书与您的域名相匹配。然后使用我们的SSL Checker进行更深入的扫描，即时获取有关证书、证书链以及您服务器所提供的协议和密码套件的报告。若结果显示为绿色，则意味着各大主流平台上的客户端（包括移动端和 API 客户端）都将信任该证书。

常见问题