1. 项目概述：为什么我们需要自制SSL证书？

在今天的互联网上，HTTPS已经从一个“加分项”变成了“必需品”。无论是个人博客、内部管理系统，还是开发测试环境，一个绿色的安全锁图标不仅能给用户带来信任感，更是现代浏览器和搜索引擎的硬性要求。然而，一提到HTTPS，很多朋友的第一反应就是“申请证书好麻烦”，或者“免费的证书只有三个月有效期，总得续签”。对于开发、测试、预发布环境，或者一些内部使用的工具网站，我们其实有更灵活、更可控的选择——那就是自己动手制作SSL证书。

你可能听说过Let‘s Encrypt，它确实伟大，提供了免费的DV证书。但在某些场景下，它并不完美：比如你的测试服务器在内网，没有公网域名；或者你需要一个有效期长达十年的证书，避免频繁更新；又或者你只是想快速验证一个HTTPS配置是否生效，不想走繁琐的申请流程。这时，自制证书（通常称为自签名证书）就成了最佳选择。它就像你给自己家大门配的一把钥匙，虽然不被外界权威机构（CA）认可，但在你自己的地盘上，它说了算。

本教程将带你从零开始，使用OpenSSL工具链，一步步创建属于你自己的根证书、服务器证书，并最终在Nginx上完成HTTPS配置。整个过程完全离线，无需联网申请，证书有效期、加密算法、主题信息全部由你掌控。这不仅是搭建HTTPS的捷径，更是理解HTTPS/TLS协议中证书信任链原理的绝佳实践。无论你是运维工程师、后端开发者，还是对网络安全感兴趣的技术爱好者，掌握这项技能都能让你在应对各种环境时更加游刃有余。

2. 核心原理与准备工作

2.1 HTTPS与SSL/TLS证书简析

在动手之前，我们有必要花几分钟理清几个核心概念，这能帮你理解每一步操作背后的意义，而不是机械地复制命令。

HTTPS的本质，是在HTTP协议的基础上，套了一层SSL/TLS协议的安全外壳。这层外壳主要解决两个问题：加密和身份验证。加密确保了传输过程中的数据（如密码、聊天内容）即使被截获也无法被破解；身份验证则确保了和你通信的服务器就是它声称的那一个，而不是一个钓鱼网站。

SSL/TLS证书就是这个“身份验证”环节的核心凭证。它遵循X.509标准，里面包含了服务器的公钥、所有者信息（如域名）、签发者信息以及一个至关重要的数字签名。浏览器之所以信任某个证书，并不是因为它本身，而是因为它是由一个浏览器内置信任的根证书颁发机构（Root CA）签发的。这就构成了一条信任链：浏览器信任根CA -> 根CA签名证明了中间CA可信 -> 中间CA签名证明了你的服务器证书可信。

而我们自制的证书，相当于自己扮演了“根CA”的角色。我们创建一个自己的根证书，然后用这个根证书去签发服务器证书。由于我们的根证书不在浏览器或操作系统的信任列表里，所以访问时会提示“不安全”。但对于内部环境，我们可以手动将自制的根证书导入到系统或浏览器的信任区，这样之后访问由它签发的所有服务器证书，都会显示为安全。

2.2 工具选择与环境准备

制作证书的核心工具是OpenSSL。它是一个功能强大且开源的工具包，几乎在所有Linux发行版和macOS上都预装了。Windows用户可以从其官网或通过包管理器（如Chocolatey）安装。

打开你的终端，首先验证OpenSSL是否可用以及版本：

openssl version

如果显示类似OpenSSL 3.0.x或OpenSSL 1.1.1的版本信息，说明工具已就绪。本教程的命令在主流版本上通用。

接下来，为我们的证书工程创建一个独立的工作目录，避免文件散落各处：

mkdir -p ~/ssl_cert_demo && cd ~/ssl_cert_demo

所有后续生成的密钥和证书文件都将放在这个目录下。

注意：OpenSSL在生成密钥时默认会要求输入一个密码（passphrase）来保护私钥文件。对于自动化部署或测试环境，这反而会成为障碍。我们可以通过参数取消这个密码，但务必明白，这意味着私钥文件一旦泄露，攻击者可以直接使用它。因此，在生产环境或敏感场景下，请务必为私钥设置强密码并妥善保管。

3. 实操步骤一：创建私有根证书颁发机构（CA）

我们的第一步是创建自己的“证书总局”，即根CA。这需要生成一对密钥（公钥和私钥），然后创建一个自签名的根证书。

3.1 生成根CA的私钥

私钥是证书安全体系的基石，必须绝对保密。我们使用RSA算法生成一个4096位的私钥，这个长度在安全性和性能之间取得了很好的平衡。

openssl genrsa -out rootCA.key 4096

命令解释：

• genrsa: 生成RSA密钥对。
• -out rootCA.key: 指定输出的私钥文件名。
• 4096: 密钥长度，单位为比特。2048位是当前最低安全标准，4096位更安全，但握手时计算量稍大。

执行后，当前目录下会生成一个rootCA.key文件。请务必妥善备份此文件，不要提交到代码仓库或通过不安全渠道传输。

3.2 创建根CA的自签名证书

有了私钥，我们现在可以创建根证书。证书是一个包含公钥、身份信息和签名的文件。因为是根证书，所以它自己给自己签名。

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.crt

执行这个命令后，OpenSSL会进入交互式提问模式，你需要填写证书的主题信息（Subject）：

• Country Name (2 letter code)：国家代码，如CN。
• State or Province Name：州或省，如Beijing。
• Locality Name：城市，如Beijing。
• Organization Name：组织名称，如My Company Inc.。
• Organizational Unit Name：部门名称，如IT Department。
• Common Name：这是最关键的一项！对于根CA，通常填写一个易于识别的名称，如My Local Root CA。
• Email Address：邮箱地址。

命令参数详解：

• req: 证书请求和生成工具。
• -x509: 直接输出一个X.509证书，而不是证书请求（CSR）。
• -new: 生成新的证书请求。
• -nodes: 是“no DES”的缩写，意思是不对生成的私钥进行加密。这样生成的.key文件不需要密码即可使用，方便测试。
• -key rootCA.key: 指定用于签名的私钥文件。
• -sha256: 指定签名使用的哈希算法为SHA-256，更安全。
• -days 3650: 证书有效期，这里是10年（3650天）。对于自用根CA，可以设得很长。
• -out rootCA.crt: 输出的根证书文件名。

现在，你得到了两个核心文件：rootCA.key（私钥，绝密）和rootCA.crt（根证书，需要分发给需要信任你的客户端）。

4. 实操步骤二：为你的服务器创建证书

根CA建立好后，我们就可以用它来为具体的服务器（比如你的Nginx）签发证书了。这个过程分为两步：先由服务器生成一个证书签名请求（CSR），再由根CA审核（这里就是我们自己）并签发证书。

4.1 生成服务器私钥和证书签名请求（CSR）

首先，为你的Web服务器生成一个私钥：

openssl genrsa -out server.key 2048

这里我们使用2048位，对于服务器证书来说已经足够安全，并且比4096位性能稍好。

接着，使用这个私钥生成一个证书签名请求（CSR）。CSR里包含了服务器的公钥和身份信息，提交给CA用于申请证书。

openssl req -new -key server.key -out server.csr

同样会进入交互式提问，大部分信息可以和根CA不同。请特别注意Common Name (CN)字段：这里必须填写你希望通过HTTPS访问的域名或IP地址。例如，如果你的网站将通过test.example.com或192.168.1.100访问，这里就填对应的地址。如果填写错误，浏览器会报告“证书与站点名称不匹配”的错误。

4.2 使用根CA签发服务器证书

现在，我们扮演CA的角色，使用根CA的私钥和证书，对服务器的CSR进行签名，生成最终的服务器证书。

openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 825 -sha256

命令参数详解：

• x509: 证书处理工具。
• -req: 输入是一个CSR文件。
• -in server.csr: 指定输入的CSR文件。
• -CA rootCA.crt: 指定CA的证书。
• -CAkey rootCA.key: 指定CA的私钥。
• -CAcreateserial: 创建或使用一个序列号文件。CA为每个签发的证书分配唯一序列号，这里会自动生成一个rootCA.srl文件来记录。
• -out server.crt: 输出的服务器证书文件。
• -days 825: 服务器证书的有效期。这里设为825天（约2年3个月），是兼容所有主流浏览器和设备的推荐最长期限（如苹果要求服务器证书有效期不超过398天，但825天是一个广泛接受的测试值）。
• -sha256: 签名算法。

执行成功后，你会得到server.crt（服务器证书）和server.key（服务器私钥）。这两个文件就是最终需要配置到Nginx里的文件。同时，目录下还会有一个server.csr（可保留备用）和一个rootCA.srl文件。

5. 实操步骤三：在Nginx中配置HTTPS

证书准备就绪，现在让我们把它们配置到Nginx中。假设你已经安装好了Nginx。

5.1 放置证书文件

首先，将证书和私钥文件放到一个Nginx有权限读取的安全目录，通常是在/etc/nginx/ssl/或/usr/local/nginx/conf/ssl/下。我们以/etc/nginx/ssl/为例：

sudo mkdir -p /etc/nginx/ssl sudo cp server.crt server.key /etc/nginx/ssl/

确保私钥server.key的权限足够安全，通常设置为只有root可读：

sudo chmod 600 /etc/nginx/ssl/server.key

5.2 配置Nginx服务器块

编辑你的Nginx站点配置文件。可能是/etc/nginx/sites-available/default或/etc/nginx/conf.d/your-site.conf。在原有的监听80端口的server块旁边，添加一个新的server块来监听443端口（HTTPS默认端口）。

一个最基础的HTTPS配置示例如下：

server { listen 443 ssl http2; # 监听443端口，启用SSL和HTTP/2 server_name your_domain_or_ip; # 替换为你的域名或IP，必须与证书CN一致 # 指定证书和私钥的路径 ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; # SSL协议和加密套件配置，提升安全性 ssl_protocols TLSv1.2 TLSv1.3; # 禁用不安全的TLSv1.0和v1.1 ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # 其他与HTTP块相同的配置，如根目录、代理等 root /var/www/html; index index.html index.htm; location / { try_files $uri $uri/ =404; } } # 可选：将HTTP请求重定向到HTTPS server { listen 80; server_name your_domain_or_ip; return 301 https://$server_name$request_uri; }

关键配置解析：

• listen 443 ssl http2;:ssl参数告诉Nginx启用SSL/TLS；http2是可选但强烈推荐的，它能显著提升页面加载性能。
• server_name: 必须与你在生成CSR时填写的Common Name完全一致，否则浏览器会报名称不匹配错误。
• ssl_certificate和ssl_certificate_key: 指向我们刚才生成的证书和私钥文件。
• ssl_protocols: 指定允许的TLS协议版本。TLSv1.0和v1.1已被证实存在漏洞，务必禁用。
• ssl_ciphers: 指定加密套件。上述配置是一个兼顾安全性和兼容性的示例。你可以使用openssl ciphers -v查看所有可用套件。

5.3 测试配置并重启Nginx

在重启Nginx前，务必测试配置文件语法是否正确：

sudo nginx -t

如果输出syntax is ok和test is successful，说明配置无误。

然后重新加载或重启Nginx使配置生效：

sudo systemctl reload nginx # 或 sudo service nginx reload # 如果reload不行，则使用 restart # sudo systemctl restart nginx

6. 客户端信任与访问测试

配置完成后，你在服务器上的工作就结束了。但在客户端（你的电脑或手机）访问时，会因为不信任我们自签的根CA而显示“不安全”警告。为了让体验更完美，我们需要让客户端信任我们的根CA。

6.1 将根证书导入系统信任库

在Windows上：

1. 将rootCA.crt文件复制到Windows电脑。
2. 双击该文件，点击“安装证书”。
3. 选择“当前用户”或“本地计算机”，点击“下一步”。
4. 选择“将所有的证书都放入下列存储”，点击“浏览”。
5. 选择“受信任的根证书颁发机构”，点击“确定”并完成安装。

在macOS上：

1. 将rootCA.crt文件复制到Mac。
2. 双击文件，这会打开“钥匙串访问”应用。
3. 在“钥匙串”列表中选择“系统”或“登录”（系统影响所有用户，登录仅影响当前用户）。
4. 找到你刚导入的证书（名称是你在创建时填的Common Name），双击它。
5. 在“信任”部分，将“使用此证书时”设置为“始终信任”，然后关闭窗口并输入密码保存。

在Linux (Ubuntu/Debian) 上：

sudo cp rootCA.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates

在浏览器中单独导入（以Chrome为例）：如果不想影响整个系统，可以只在浏览器中导入。

1. 打开Chrome设置 -> 隐私和安全 -> 安全 -> 管理设备证书。
2. 在“受信任的根证书颁发机构”标签页，点击“导入”，然后选择你的rootCA.crt文件。

6.2 访问测试与问题排查

完成信任导入后，再次用浏览器访问你的https://your_domain_or_ip，地址栏应该显示绿色的安全锁图标，点击锁图标可以查看证书详情，应该能看到完整的信任链，从你的服务器证书一直到你自建的根CA。

如果仍然显示不安全，请按以下步骤排查：

1. 检查Nginx配置：确认ssl_certificate和ssl_certificate_key路径正确，且Nginx进程有读取权限。
2. 检查域名/IP匹配：确认浏览器访问的地址与证书中的Common Name完全一致。如果是IP访问，CN必须是IP；如果是域名访问，CN必须是域名。不支持通配符（除非你生成的是通配符证书）。
3. 检查端口：确认Nginx正在监听443端口(sudo netstat -tlnp | grep :443)。
4. 清除浏览器缓存：浏览器可能会缓存之前的证书错误状态，尝试无痕模式访问。
5. 查看Nginx错误日志：sudo tail -f /var/log/nginx/error.log，在访问时查看有无相关报错。

7. 进阶配置与优化

基础HTTPS上线后，我们可以进一步优化安全性和性能。

7.1 启用HTTP严格传输安全（HSTS）

HSTS是一种安全策略机制，它强制浏览器只通过HTTPS与网站通信，防止协议降级攻击。在Nginx的HTTPSserver块中添加：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

• max-age=31536000：告诉浏览器在接下来的一年（31536000秒）内，对于该域名及其子域名，都只能使用HTTPS访问。
• includeSubDomains：此策略也适用于所有子域名。
• 重要警告：一旦启用并经过浏览器接收，在有效期内撤销会非常困难。建议先在测试环境验证，确认HTTPS完全稳定后再在生产环境添加。

7.2 优化SSL会话缓存

SSL/TLS握手是一个计算密集型过程。启用会话缓存可以减少重复握手，提升性能。

ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;

• ssl_session_cache shared:SSL:10m：在多个工作进程间共享一个10MB大小的SSL会话缓存。
• ssl_session_timeout 10m：会话超时时间为10分钟。

7.3 使用更强的Diffie-Hellman参数

Diffie-Hellman（DH）密钥交换用于协商前置主密钥。使用一个更强的DH参数文件可以增强前向安全性。

sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

然后在Nginx配置中添加：

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

生成2048位的DH参数可能需要几分钟时间，请耐心等待。

8. 常见问题与解决方案实录

在实际操作中，你可能会遇到以下问题，这里记录了我的排查经验和解决方案。

问题1：浏览器提示“您的连接不是私密连接”（NET::ERR_CERT_AUTHORITY_INVALID）

• 原因：浏览器不信任签发服务器证书的根证书（即我们的rootCA.crt）。
• 解决：确保已将rootCA.crt正确导入到客户端系统的“受信任的根证书颁发机构”存储中，并重启浏览器。在测试阶段，你也可以在浏览器警告页面点击“高级”->“继续前往（不安全）”，但这仅用于临时测试。

问题2：浏览器提示“证书与站点名称不匹配”

• 原因：浏览器访问的地址（域名或IP）与证书中Common Name (CN)字段的内容不一致。
• 解决：重新生成CSR和证书，确保在填写CN时，准确填写你将要用来访问的完整地址。例如，用域名访问就填域名www.test.com，用IP访问就填IP192.168.1.100。一个证书只能对应一个具体的CN。

问题3：Nginx启动或重载失败，报错“SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch”

• 原因：Nginx配置中ssl_certificate指定的证书文件与ssl_certificate_key指定的私钥文件不匹配。它们不是一对。
• 解决：检查并确认你使用的是由同一个私钥（server.key）生成的CSR所签发出的证书（server.crt）。一个快速验证的方法是：openssl x509 -noout -modulus -in server.crt | openssl md5和openssl rsa -noout -modulus -in server.key | openssl md5，如果两个命令输出的MD5值相同，则匹配。

问题4：移动端或某些旧设备无法访问

• 原因：可能是由于SSL协议版本或加密套件不兼容。
• 解决：
  1. 检查ssl_protocols是否包含了TLSv1.2。对于需要兼容非常老的客户端（如Android 4.x），可能还需要加上TLSv1，但请注意安全风险。
  2. 使用更兼容的加密套件。可以尝试使用Mozilla推荐的“Intermediate”兼容性配置。也可以使用在线工具（如SSL Labs测试）来检查你的服务器配置对各类客户端的兼容性。

问题5：如何为多个子域名或域名制作证书？

• 解决：你需要生成一个主题备用名称（SAN）证书。在生成CSR时，需要创建一个包含subjectAltName字段的配置文件。这比单CN证书更复杂，但更符合现代浏览器的要求。基本步骤是：创建一个配置文件server.cnf，在其中定义req_extensions和subjectAltName，然后在生成CSR时通过-config server.cnf参数引用它。这是制作更通用内部证书的进阶技能。

自制SSL证书是掌握HTTPS原理和应对内网开发测试需求的利器。它把证书的生成、签发和信任的控制权完全交还给你。虽然自签名证书在公网环境下会因为不被广泛信任而显示警告，但在可控的私有环境中，它提供了无与伦比的便捷性和灵活性。通过本教程的实践，你不仅成功搭建了一个HTTPS站点，更深入理解了证书信任链的运作机制。下次当你需要快速搭建一个临时的、安全的测试环境时，这套流程将会是你的得力工具。