1. 项目概述为什么内网也需要HTTPS最近在给公司内部几个新系统做部署开发同事跑过来问“老大咱们内网服务用HTTP行不行反正外网也访问不到。” 我直接给他看了浏览器上那个刺眼的“不安全”提示还有测试环境里因为混用HTTP/HTTPS导致的前端API调用失败。这场景太常见了很多团队觉得内网环境“安全”就忽略了传输加密。但实际上现代浏览器对非HTTPS站点的限制越来越严格一些新的Web API比如地理位置、Service Worker甚至要求必须在安全上下文中运行。更不用说内网也可能存在嗅探风险尤其是办公网这种人员复杂的环境。所以这篇指南的核心就是帮你用OpenSSL这个“瑞士军刀”亲手打造一套完全受控的内网HTTPS证书体系。无论是给开发测试环境、内部管理后台还是物联网设备、微服务间的通信加密都能搞定。我们不止步于生成一个证书更要讲清楚怎么避开那些新手甚至老手常踩的坑比如证书链不完整、IP地址扩展项没配、证书过期时间设得太短反复折腾等等。我会带你从原理到实操覆盖用IP直接访问和用自定义域名访问两种最主流的场景让你以后在内网安全这块心里彻底有底。2. 核心思路与避坑总览在动手之前我们先理清思路并看清路上有哪些“坑”。用OpenSSL自签证书本质上是自己扮演“根证书颁发机构CA”然后由这个自建的CA去签发服务器证书。这样做的好处是绝对可控、免费、无需与外部CA交互。但随之而来的挑战就是你需要自己管理整个信任链。第一个大坑忽略完整的证书链。很多教程只教你生成一个服务器证书server.crt然后就往Nginx里一配。结果浏览器访问时虽然证书“有效”但会提示“此证书并非由受信任的机构颁发”。这是因为浏览器只收到了叶子证书服务器证书但没有收到签发它的中间CA或根CA证书。正确的做法是构建一个完整的链根CA - 可选中间CA - 服务器证书。在配置Web服务器时通常需要将服务器证书和中间CA证书如果有合并成一个文件传给服务器。第二个大坑对IP地址的支持不完整。内网服务直接用IP访问非常方便比如https://192.168.1.100。但标准的SSL/TLS证书是针对域名Common Name, CN设计的。要让证书支持IP地址必须在生成证书签名请求CSR和最终证书时使用subjectAltName(SAN) 扩展字段明确指定IP地址。很多用旧版OpenSSL或简单命令生成的证书缺了这个扩展导致用IP访问时浏览器报“名称不匹配”错误。第三个大坑证书参数设置不合理。这包括密钥强度不足还在用默认的1024位RSA这在今天已经不够安全了。我们至少应该使用2048位有条件直接上4096位或使用更现代的ECDSA算法。有效期太短或太长测试证书设个1年结果项目延期证书先过期了服务突然中断。设个100年虽然省事但不符合安全最佳实践而且一些严格的客户端或库可能会拒绝过长期限的证书。我们需要一个平衡点。信息随意填写虽然自签证书但Country Name、Organization Name等字段最好按规范填写尤其是当证书需要在多个系统或设备间共享时统一的规范能减少不必要的麻烦。理解了这三个核心陷阱我们接下来的每一步操作都会有针对性地避开它们。3. 环境准备与OpenSSL配置工欲善其事必先利其器。首先确保你的系统上安装了OpenSSL。通过openssl version命令可以查看版本。推荐使用1.1.1或更新版本它们对SAN扩展的支持更好命令也更统一。接下来是关键一步配置OpenSSL的默认配置文件。OpenSSL在很多操作如生成CSR、签名证书时会读取一个默认的配置文件通常是/etc/ssl/openssl.cnf或/usr/lib/ssl/openssl.cnf。我们可以复制一份到工作目录进行修改这样不会影响系统全局配置。# 找到并复制配置文件到当前目录 cp /etc/ssl/openssl.cnf ./myopenssl.cnf然后编辑myopenssl.cnf我们需要重点关注[ req ]、[ v3_ca ]和[ v3_req ]这几个段落。主要修改是确保请求和证书能包含我们需要的扩展字段特别是subjectAltName(SAN)。在[ req ]段落下确保或添加[ req ] ... req_extensions v3_req # 这行很重要表示在生成CSR时要包含v3_req段中定义的扩展 ...在[ v3_req ]段落下配置基本的扩展。我们这里先配一个通用模板具体的IP和域名将在生成时动态替换[ v3_req ] basicConstraints CA:FALSE keyUsage nonRepudiation, digitalSignature, keyEncipherment #extendedKeyUsage serverAuth, clientAuth # 如果需要双向认证mTLS可以取消注释clientAuth subjectAltName alt_names # 关键指向一个存放SAN的段落然后在文件末尾或任何位置添加[ alt_names ]段落。这里我们先留空因为IP和域名每次可能不同我们将在实际生成证书时通过命令行参数或临时修改这个文件来注入具体值。[ alt_names ] # 示例 # DNS.1 internal.app.com # IP.1 192.168.1.100 # IP.2 10.0.0.1注意有些较老的教程会教你修改[ req_distinguished_name ]来预设国家、公司等信息这样可以免去交互式提问。但对于我们这种需要灵活生成多场景证书的情况我更推荐在命令行中通过-subj参数一次性指定这样更清晰、可脚本化。配置文件我们主要用来控制扩展Extensions行为。4. 详细实操构建私有CA并签发证书现在进入核心实操环节。我们将遵循“根CA - 服务器证书”的两级结构这已能满足绝大多数内网需求。如果需要更复杂的多级管理可以在此基础上增加中间CA。4.1 第一步创建自己的根证书颁发机构CA根CA是信任的起点。我们需要为它生成一个私钥和一个自签名的根证书。1. 生成根CA的私钥这里我们直接使用4096位的RSA密钥确保安全强度。openssl genrsa -out rootCA.key 4096genrsa: 生成RSA私钥。-out rootCA.key: 指定输出的私钥文件名。4096: 密钥长度。对于根证书长一点更安全。2. 生成根CA的自签名证书使用上一步的私钥创建一个有效期为10年3650天的根证书。openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.crt -subj /CCN/STBeijing/LBeijing/OMyInternalOrg/OUIT Department/CNMy Internal Root CAreq -x509: 直接生成一个自签名的X.509证书而不是证书请求。-new: 生成新的证书请求对于-x509来说就是生成新证书。-nodes: 不对私钥进行加密。对于自动化部署的CA密钥通常不加密但务必妥善保管此文件-key rootCA.key: 指定用于签名的私钥。-sha256: 使用SHA-256哈希算法不要使用已不安全的SHA-1。-days 3650: 证书有效期。-subj “/C…/CN…”: 以非交互方式设置证书主题。这里CN设为“My Internal Root CA”这是一个清晰的标识。实操心得根CA的私钥 (rootCA.key) 是你整个内网证书体系的命门。一旦泄露攻击者可以用它签发任何会被你内网信任的假证书。务必将其存放在极度安全、离线的地方如加密的U盘只在需要签发新证书时才临时取出使用。日常服务器配置只需要rootCA.crt文件。4.2 第二步生成服务器证书支持IP和域名这是最灵活的一步我们将演示如何生成一个同时支持通过IP地址和域名访问的服务器证书。1. 生成服务器私钥openssl genrsa -out server.key 2048服务器证书的私钥使用2048位RSA是当前安全与性能的平衡点。2. 创建证书签名请求CSRCSR包含了你的服务器信息和公钥待CA签名后即成证书。关键点在于如何包含多个主题备用名称SAN。 首先我们创建一个专门用于此次请求的配置文件server_csr.cnf内容如下[ req ] default_bits 2048 prompt no default_md sha256 req_extensions req_ext distinguished_name dn [ dn ] C CN ST Beijing L Beijing O MyInternalOrg OU Dev CN internal.app.com # 这里填写主域名即使你用IP访问也最好设一个 [ req_ext ] subjectAltName alt_names [ alt_names ] DNS.1 internal.app.com DNS.2 *.dev.internal.app.com # 支持通配子域名 IP.1 192.168.1.100 IP.2 10.10.0.1 # 可以继续添加更多DNS或IP然后使用此配置生成CSRopenssl req -new -key server.key -out server.csr -config server_csr.cnf-config server_csr.cnf: 指定我们自定义的配置文件它定义了主题信息和最重要的SAN扩展。3. 使用根CA为CSR签名生成服务器证书同样我们需要一个签名配置文件来指定证书扩展属性。创建server_cert_ext.cnfauthorityKeyIdentifierkeyid,issuer basicConstraintsCA:FALSE keyUsage digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName alt_names # 必须与CSR中的一致或者在这里重新定义 [ alt_names ] DNS.1 internal.app.com DNS.2 *.dev.internal.app.com IP.1 192.168.1.100 IP.2 10.10.0.1执行签名命令openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 825 -sha256 -extfile server_cert_ext.cnfx509 -req: 处理证书请求。-in server.csr: 输入CSR文件。-CA rootCA.crt -CAkey rootCA.key: 指定CA的证书和私钥。-CAcreateserial: 创建或使用一个序列号文件确保每个证书有唯一序列号。-out server.crt: 输出最终的服务端证书。-days 825: 有效期约2年零3个月。这是目前一个比较推荐的时间既不会太短需要频繁更换也符合减少证书最长有效期的安全趋势。-extfile server_cert_ext.cnf:这是避开第二个坑的关键通过此参数指定包含SAN等扩展的配置文件。如果不加生成的证书将不包含SAN信息IP访问会失败。至此你得到了三个关键文件server.key: 服务器私钥。server.crt: 服务器证书叶子证书。rootCA.crt: 根CA证书。对于Web服务器如Nginx配置通常需要将server.crt和rootCA.crt合并成一个文件因为Nginx的ssl_certificate指令需要包含完整的证书链从叶子证书到根证书中间证书在前根证书在最后。由于我们只有两级命令如下cat server.crt rootCA.crt server-chain.crt然后在Nginx配置中ssl_certificate指向server-chain.crtssl_certificate_key指向server.key。5. 多场景配置详解与服务器部署生成了证书接下来就是用了。我们分两种最常见的内网场景来配置。5.1 场景一使用IP地址直接访问如 https://192.168.1.100这是开发测试环境中最常用的方式。配置要点在于之前生成证书时alt_names里必须包含目标IP地址如IP.1 192.168.1.100并且CN字段虽然要求是域名但可以设置为一个描述性名称如internal-app这通常不影响IP访问因为浏览器主要校验SAN。Nginx配置示例server { listen 443 ssl http2; # 监听所有IP或指定 server_name _; server_name _; # 使用通配或默认 ssl_certificate /path/to/your/certs/server-chain.crt; ssl_certificate_key /path/to/your/certs/server.key; # 可选增强SSL配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:...; ssl_prefer_server_ciphers off; location / { root /usr/share/nginx/html; index index.html; } }配置完成后重启Nginx。在客户端浏览器访问https://192.168.1.100你会看到一个安全警告因为浏览器不信任我们的自签根CA。这时需要将之前生成的rootCA.crt文件导入到客户端的操作系统或浏览器的“受信任的根证书颁发机构”存储中。导入后警告消失连接显示为安全。5.2 场景二使用自定义内网域名访问如 https://myapp.internal这种方式更接近生产环境体验更好。你需要在内网DNS服务器或者客户机的hosts文件如C:\Windows\System32\drivers\etc\hosts或/etc/hosts中将域名myapp.internal解析到服务器的内网IP地址。证书生成时alt_names里必须包含该域名如DNS.1 myapp.internal。CN字段通常也设置为这个域名。Nginx配置示例server { listen 443 ssl http2; server_name myapp.internal; # 明确指定域名 ssl_certificate /path/to/your/certs/server-chain.crt; ssl_certificate_key /path/to/your/certs/server.key; # ... 其他SSL优化配置同上 location / { proxy_pass http://localhost:8080; # 例如反向代理到本地应用 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }同样客户端需要信任rootCA.crt。之后访问https://myapp.internal即可。注意事项对于移动端Android/iOSApp或某些客户端软件它们可能有自己独立的证书信任库。你需要将rootCA.crt以适当的方式如通过移动设备管理MDM、或打包进App资源安装到对应设备的信任存储中否则HTTPS请求会失败。6. 客户端信任安装与自动化脚本让每个访问内网服务的客户端都手动安装根证书是不现实的尤其是当客户端很多或经常变动时。这里分享一些方法。对于Windows域环境可以通过组策略Group Policy将根证书自动分发并安装到域内所有计算机的“受信任的根证书颁发机构”存储中。这是最集中、最有效的管理方式。对于macOS可以使用描述文件.mobileconfig或MDM解决方案如Jamf来部署证书。对于Linux服务器/客户端可以将rootCA.crt复制到/usr/local/share/ca-certificates/目录然后运行sudo update-ca-certificates命令来更新系统证书库。对于基于RHEL/CentOS的系统可以复制到/etc/pki/ca-trust/source/anchors/然后运行sudo update-ca-trust。自动化签发脚本对于需要频繁为不同服务签发证书的场景可以编写一个Shell脚本来自动化整个过程。脚本可以接收IP和域名作为参数动态生成配置文件并执行OpenSSL命令。这里提供一个极简的思路框架#!/bin/bash # 示例脚本auto_gen_cert.sh SERVER_IP$1 SERVER_DNS$2 # 1. 创建临时配置文件用sed替换IP和DNS cat /tmp/csr_config.cnf EOF ... [ alt_names ] DNS.1 ${SERVER_DNS} IP.1 ${SERVER_IP} EOF # 2. 生成私钥和CSR openssl genrsa -out ${SERVER_DNS}.key 2048 openssl req -new -key ${SERVER_DNS}.key -out ${SERVER_DNS}.csr -subj /CCN/OMyOrg/CN${SERVER_DNS} -config /tmp/csr_config.cnf # 3. 使用根CA签名假设根CA文件在固定位置 openssl x509 -req -in ${SERVER_DNS}.csr -CA /secure/path/rootCA.crt -CAkey /secure/path/rootCA.key -CAcreateserial -out ${SERVER_DNS}.crt -days 825 -sha256 -extfile /tmp/csr_config.cnf # 4. 清理和输出 echo 证书生成完成: ${SERVER_DNS}.key, ${SERVER_DNS}.crt使用方式./auto_gen_cert.sh 192.168.1.100 myapp.internal7. 高级话题双向认证mTLS与证书生命周期管理在某些安全要求极高的内网场景比如微服务之间的通信你可能需要双向TLS认证mTLS。这意味着不仅服务器要向客户端证明自己通过服务器证书客户端也要向服务器证明自己通过客户端证书。实现概要创建客户端证书流程与创建服务器证书几乎相同。通常由同一个私有CA签发。在生成CSR和证书时extendedKeyUsage应包含clientAuth。CN字段可以设置为客户端标识如服务名称svc-auth。服务器端配置Nginxserver { ... ssl_client_certificate /path/to/your/ca-chain.crt; # 信任的CA证书用于验证客户端证书 ssl_verify_client on; # 开启客户端证书验证 ssl_verify_depth 2; # 验证深度 # 可以根据客户端证书的CN等信息做更细粒度的访问控制 if ($ssl_client_s_dn ! “CNsvc-auth”) { return 403; } }客户端使用在发起HTTPS请求时如使用curl、Postman或编程语言库需要加载自己的客户端证书.crt和私钥.key。证书生命周期管理自签证书虽然自由但管理责任也全在自己。建议建立简单的管理规范登记簿用一个表格或文档记录签发的每张证书的用途服务名、关联的IP/域名、签发日期、过期日期、使用的SAN等。监控过期写一个定时任务cron job定期检查证书目录下所有.crt文件的过期时间并在过期前30天、7天发送告警。可以使用命令openssl x509 -in server.crt -noout -enddate来查看过期时间。轮换流程制定证书更新流程。在旧证书过期前生成新证书部署到服务并重启。由于是自签CA只要根CA不变更新服务器证书对客户端是透明的客户端已信任根CA。根CA证书有效期很长但也要在过期前很久就计划生成新的根CA并引导所有客户端迁移信任这个过程更复杂。8. 常见问题与故障排查实录在实际操作中你几乎一定会遇到下面这些问题。我把它们和排查思路整理成了速查表。问题现象可能原因排查命令与解决方案浏览器提示“不是私密连接”、“证书无效”或“此证书并非由受信任的机构颁发”。1. 客户端未安装或未正确信任根CA证书 (rootCA.crt)。2. 服务器配置的证书链不完整只发送了叶子证书 (server.crt)。排查1. 确认客户端已正确导入rootCA.crt到“受信任的根证书颁发机构”。2. 使用openssl s_client -connect 192.168.1.100:443 -showcerts命令连接服务器查看输出的证书链。应该能看到服务器证书和可能的中间CA证书。如果只有一张证书说明链不完整。解决配置Web服务器时ssl_certificate应指向包含完整证书链的文件如server-chain.crt。用IP访问时浏览器提示“证书中的名称无效”或“名称不匹配”。证书中缺少该IP地址的subjectAltName(SAN) 扩展。排查openssl x509 -in server.crt -text -noout用域名访问时提示“名称不匹配”。1. 证书SAN中未包含该域名。2. 浏览器访问的域名与证书中的CN或SAN不匹配比如大小写、www前缀。排查同上命令检查SAN中的DNS条目。同时检查证书的Subject: CN字段。解决确保证书SAN包含所有需要访问的域名变体如example.com和www.example.com。Nginx启动失败报错SSL_CTX_use_PrivateKey或key values mismatch。服务器证书 (.crt) 和私钥 (.key) 不匹配。排查分别计算它们的MD5值RSA密钥或直接使用OpenSSL验证openssl x509 -noout -modulus -in server.crt客户端工具如curl、wget报错self signed certificate或unable to verify the first certificate。工具不信任自签证书。解决以curl为例1.临时忽略验证不推荐用于生产curl -k https://...2.指定信任的CA证书curl --cacert /path/to/rootCA.crt https://...3.将CA证书永久添加到系统或工具的信任库。证书即将过期或已过期服务中断。证书有效期设置不合理或未监控。解决1. 紧急处理立即用相同CA签发新证书并更换。2. 长期方案建立证书过期监控告警机制并制定标准的证书轮换流程见第7节。一个我踩过的坑有一次在Docker容器内生成证书所有步骤都对但Nginx就是报错。折腾半天发现原来是我在Windows主机上用编辑器修改了OpenSSL的.cnf配置文件然后复制进Linux容器。Windows的换行符CRLF和LinuxLF不兼容导致OpenSSL解析配置文件出错。后来用dos2unix命令转换了一下文件格式就解决了。所以在跨平台操作配置文件时务必注意换行符问题。最后关于工具的选择除了命令行也有一些图形化工具可以帮助管理自签证书比如XCA。但对于需要集成到自动化流水线CI/CD中的场景命令行脚本仍然是唯一可靠的选择。这份指南提供的命令和思路已经可以覆盖从零开始搭建到自动化运维的绝大部分需求。关键在于理解每个步骤背后的目的这样无论遇到什么环境或工具链你都能灵活应对。