很多朋友第一次给自己的站点配 HTTPS 的时候第一反应都是去搜“ssl 证书免费申请指南”然后在各种云厂商、国外服务商之间来回比较最后反而被一堆 DV、OV、EV、证书链、泛域名、自动续期这些概念绕晕。这篇内容就围绕免费 SSL 证书从“申请”到“部署”再到“排查报错”的完整链路来写把我实际跑过的流程、踩过的坑、以及验证过能用的方案一次性说清楚。这篇文章适合三类人刚接触 HTTPS 的站长、需要给内部系统或测试环境配证书的运维开发、以及被各种 ssl 错误和证书不受信任问题折磨的排查党。无论你是要用 Nginx 还是 Tomcat是买云服务器还是家里 NAS 自建服务看完基本都能自己上手。我个人做过的项目里既给线上业务配过正规的 DV 免费证书也给内网工具签发过自签名证书还在 Nginx、Tomcat、Java 客户端、数据库连接串这些环节里遇到过各种证书报错。所以这篇不是单纯把申请步骤抄一遍更多是把“为什么这么选”“为什么报这个错”讲清楚。证书这件事表面看是“申请一个文件放服务器上”实际上涉及信任链、验证方式、有效期管理、中间证书拼接等一堆细节。下面按完整流程来走一遍。1. 证书类型与免费证书的选择1.1 免费证书和付费证书到底差在哪先说一个最基础的问题HTTPS 证书分为 DV、OV、EV 三个级别免费证书几乎都是 DV 证书也就是只验证域名所有权。花钱买的证书里OV 和 EV 会验证企业身份浏览器地址栏会显示公司名称甚至绿色大号企业标识这个能力免费证书给不了也不需要给——99% 的个人站点和中小业务根本用不到这种展示型信任标识。从加密强度上看DV、OV、EV 的加密能力本身没有区别用的都是同样的 TLS 握手和密钥交换机制。区别只在“证书里写的身份信息有多详细”和“签发机构做了多深的审核”。所以如果你的需求只是让网站地址栏变成小锁、让数据在传输过程中不被明文抓包免费 DV 证书完全够用。这也是我自己的习惯个人博客、工具站、测试环境、API 服务一律免费证书企业级对外交易平台才需要考虑付费证书而且主要目的不是加密而是那个“企业认证标识”。有效期也是一个关键差异。免费证书现在基本都是 90 天有效期付费证书可以买一年甚至两年。这个差异很多人忽略导致用免费证书的人经常遇到“证书过期、网站突然打不开”的问题。解决办法不是放弃免费证书而是把续期做成自动化后面专门讲。还有一个隐藏差异免费证书通常不支持通配符/泛域名也就是*.example.com这种格式。大部分云厂商的免费证书只支持绑定一个具体的二级域名example.com和www.example.com都要分别申请。这个限制在域名多、子域名多的情况下会非常难受。1.2 免费证书的主要来源与选型思路免费证书来源主流有三个方向第一类是 Lets Encrypt。这是目前全球使用量最大的免费证书机构有成熟的开源客户端 Certbot支持 HTTP 验证和 DNS 验证可以签发单域名、多域名SAN和泛域名证书。它的最大优点是全自动续期、生态完善、所有主流服务器软件都有现成插件。缺点是证书有效期只有 90 天必须靠定时任务自动续期如果服务器没有外网访问权限或者域名解析不标准自动续期容易失败。第二类是云厂商的免费证书比如阿里云、腾讯云都有每年一定数量的免费 DV 证书额度。申请流程在控制台里点几下就行不需要在服务器上装客户端审核也快一般几分钟到几小时就发下来了。它的好处是申请门槛极低、适合不熟悉命令行的用户缺点是不能泛域名、有效期一般也是一年或更短、续期麻烦快到期的前一个月手动重新申请而且不适用于某些特殊情况下的纯命令行服务器。第三类是一些第三方免费 CA比如 ZeroSSL、SSL.com 的免费套餐。这类更边缘一些主要给那些不方便用 Lets Encrypt 自动化或者需要更灵活验证方式的场景。比如 ZeroSSL 提供 90 天免费证书支持网页验证、DNS 验证和文件验证三种方式但是它的免费套餐有证书数量限制密钥和 CSR 可以在线生成对比之下没有 Lets Encrypt 那么开箱即用。以我的经验如果是云服务器用户优先用云厂商免费证书因为下载下来格式齐全Nginx、Apache、IIS、Tomcat 都有对应格式包放服务器上就能用省去自己处理证书链的麻烦。如果是自己管理一批服务器、追求自动化直接上 Lets Encrypt Certbot。两套方案不冲突可以共存比如主域名用云厂商证书、自动续期麻烦那就写个脚本到期前重新申请内部服务和测试环境统一用 Certbot 管理。2. 申请前的准备域名、解析与验证方式2.1 证书验证的本质证明域名是你的很多人第一次申请证书时会卡在“验证”这一步觉得莫名其妙。其实证书机构没那么关心你是谁它只关心一件事你是不是真的控制这个域名。这就好比你找居委会开证明人家不看你长相只看你户口本在不在这个地址上。常见的验证方式有三种我分别说一下适用场景DNS 验证给你一个 TXT 记录值让你加到域名的 DNS 解析里。证书机构会去查询这个 TXT 记录查到了就认为你拥有域名。这种方式适合有域名解析控制台权限的任何人不需要服务器在线也是申请泛域名证书的唯一方式。HTTP 文件验证证书机构给你一个随机文件名和内容让你放到网站根目录的/.well-known/pki-validation/路径下然后它去访问http://你的域名/该路径来验证。这种方式要求你的服务器 80 端口可访问并且域名已经解析到这台服务器。邮件验证证书机构给域名的 WHOIS 邮箱或常用管理员邮箱比如admin你的域名发一封验证邮件点一下链接就完成。这种方式现在比较少见主流 CA 基本都用前两种。我每次新建证书前都会先确认域名解析已经生效用dig或在线工具查一下解析记录再决定用哪种验证。申请 Lets Encrypt 的时候如果域名刚好指向这台服务器HTTP 验证很简单如果域名解析在别的服务器上用 DNS 验证更稳妥。云厂商控制台里申请证书时如果你用它的 DNS 服务通常能做到“自动添加解析记录”连复制粘贴 TXT 记录的步骤都省了。2.2 域名规划单域名、多域名与泛域名的取舍申请之前想清楚你到底需要哪种证书可以省掉后面很多重复劳动。单域名证书只能保护一个域名比如www.example.com。云厂商免费证书基本都是这种。适合只有一两个核心域名的场景。多域名证书SAN 证书一张证书可以同时保护多个完全不同的域名比如a.com、b.com、www.c.com。Lets Encrypt 默认就支持在一张证书里加最多 100 个域名只要这些域名都在你的控制下。这种适合域名不多但分散的场景。泛域名证书保护*.example.com下的所有二级域名。一旦你有很多子域名比如api.、blog.、app.、m.泛域名证书是最省心的方案签一次全部覆盖。Lets Encrypt 支持签发泛域名但只能用 DNS 验证。云厂商免费证书基本不提供泛域名这也是很多人从云厂商转向 Lets Encrypt 的原因。做技术选型时我有一个建议个人项目优先单域名脚本自动续期公司内部有多个子域名的直接上 Lets Encrypt 泛域名证书如果项目域名就三五个且不常变可以用多域名证书把全部塞进一张里省得管理多个文件。2.3 服务器环境准备Nginx 和端口放行证书申请下来最终要部署到服务器上所以服务器环境最好提前准备好。这里以 Nginx 为例先把必要的环境检查做一遍nginx -v openssl version如果 Nginx 没装Ubuntu/Debian 系统可以用apt install nginxCentOS/RHEL 系统用yum install nginx。OpenSSL 一般系统自带版本最好在 1.1.1 以上这样 TLS 1.3 才支持得比较好。还要确认服务器安全组和防火墙放行了 443 端口。很多新手排错一整天最后发现是阿里云/腾讯云控制台的安全组没放行 443。强烈建议在申请证书之前就用telnet 你的域名 443或nc -vz 你的域名 443测一下端口通不通免得部署完证书发现外网访问不了还以为是证书的问题。如果只是做本地测试或者内网部署不需要申请公网证书直接用自签名证书就行。但要注意自签名证书不会得到浏览器信任访问时会提示“此 CA 根目录证书不受信任”解决方法是把自签名的 CA 证书导入到系统或浏览器的受信任根证书列表。后面排错部分我会单独说这个。3. 免费证书申请完整实操3.1 云厂商免费证书的申请流程用阿里云举例这是大家最熟悉的方式。登录阿里云控制台搜索“数字证书管理服务”进入后选择“证书申请”类型选“DV 单域名证书”然后选择“免费证书”规格。填好证书绑定域名、申请人的联系方式提交后它会让你选择验证方式。如果你在阿里云解析一般选“自动 DNS 验证”它会自动添加一条 TXT 记录等审核就行。审核时间通常几分钟到半小时通过后在证书列表里找到这张证书点击“下载”。下载页面会按服务器类型给你不同的文件选 Nginx 会得到xxx.pem和xxx.key两个文件。pem是公钥证书也可能包含中间证书链看厂商key是私钥。这两个文件是给 Nginx 用的后面部署时直接引路径。这里有个容易踩的坑云厂商的免费证书有些在下载时只给一个pem文件这个文件里其实包含了服务器证书和 CA 中间证书拼接好的链。如果它分开给你需要自己把中间证书追加到服务器证书后面。很多朋友误以为pem文件就是纯证书拿去检查发现证书链不完整导致有些客户端访问时报unable to get local issuer certificate或ssl certificate problem。判断方法很简单打开pem文件应该能看到两个或三个-----BEGIN CERTIFICATE-----段落只有一段就是不完整。腾讯云的操作逻辑类似只是控制台入口名称和布局不同。其他云厂商流程大同小异基本都是“控制台申请→域名验证→下载→部署”四步。云厂商还有个好处支持证书到期前提醒这个对不习惯自动化的人很友好。3.2 Lets Encrypt 使用 Certbot 申请与自动续期如果你自己有独立的服务器我更推荐用 Certbot 直接申请 Lets Encrypt 证书。它的工作原理是Certbot 在服务器上临时启动一个验证服务Lets Encrypt 的服务器会访问你这个域名的 80 端口来验证所有权验证通过后证书直接签发到本地。整个过程不需要登录云厂商控制台也不需要复制粘贴验证记录。以 Ubuntu Nginx 为例apt install certbot python3-certbot-nginx certbot --nginx -d example.com -d www.example.com第一次运行会提示输入邮箱地址、同意服务条款然后自动检测 Nginx 配置、完成验证、下载证书并把证书路径自动写进 Nginx 配置。Certbot 会自动配置 80 端口跳转到 443并且把 HTTP/2 一并打开。这个过程中如果报错绝大多数原因是 80 端口没放行或者域名没解析到这台服务器。继续执行自动续期的配置Certbot 已经自带了定时任务。运行下面命令确认续期配置没问题certbot renew --dry-runCertbot 的续期机制是证书到期前 30 天内才会真正续期每天跑一次 renew 定时任务到时间了会自动续。定时任务在安装时自动创建一般路径是/etc/cron.d/certbot如果系统是 Ubuntu 18.04 以上它会用 systemd timer 来调度。你需要确认的是服务器时间准确跑一下date看时间对不对时间偏太多会导致续期失败以及域名解析没变。续期成功后它会自动 reload Nginx通常不需要人为干预。这条链路也是最稳的装一次 certbot管一年证书真正做到了“免费且不操心”。3.3 泛域名证书申请DNS 验证与手动模式泛域名证书的申请方式和单域名有些不同因为需要 DNS 验证Certbot 无法直接操作第三方 DNS 平台的解析记录所以需要手动指定验证方式。Certbot 支持--manual模式会生成一条 TXT 记录让你自己去 DNS 控制台添加certbot certonly --manual --preferred-challenges dns -d *.example.com -d example.com运行后会出现类似_acme-challenge.example.com. TXT 一串随机值的记录要求然后等待 DNS 生效Certbot 每 30 秒检查一次一般等一两分钟就会检测到并签发证书。这里我分享一个实操经验泛域名证书用 Certbot 手动模式申请但如果域名在阿里云解析会产生配置 DNS 验证插件certbot-dns-aliyun之类的第三方工具可以实现全自动续期。更简单的替代方案是用云厂商的泛域名付费证书或者把域名转入支持 ACME DNS API 的 DNS 服务商这样 Certbot 可以通过 API 自动添加 TXT 记录并完成续期。国内常见 DNS 服务商很多都提供 API配置好自己的 AccessKey 后续期就完全自动化了。对大多数场景来说单域名证书已经完全够用。泛域名主要解决的是“子域名太多不想一张张签”的痛点。如果只有两三个子域名老老实实签多域名 SAN 证书就好别为了泛域名给自己增加配置复杂度。4. 证书部署与常见配置细节4.1 Nginx 配置 HTTPS 站点拿到证书文件后pem和key把它放到一个固定目录比如/etc/nginx/ssl/。然后修改 Nginx 站点配置server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; root /var/www/html; index index.html; }改完配置先测试一下语法nginx -t确认无误后重载配置systemctl reload nginx这里有个关键点ssl_certificate指向的pem文件必须包含完整证书链。怎么验证呢用 OpenSSLopenssl s_client -connect example.com:443 -servername example.com输出中会有一行Verify return code: 0 (ok)这就表示证书链完整且受信任。如果看到unable to get local issuer certificate说明中间证书缺失需要把 CA 的中间证书追加到pem文件里。很多云厂商下载的 Nginx 证书包里就是完整的但用 Certbot 申请的有时需要手动将fullchain.pem和privkey.pem分别对应到 Nginx 的两项配置大多数情况不用拼。4.2 证书链不完整与自签名证书问题证书链不完整是 HTTPS 部署中最常见的问题之一。表现是浏览器访问正常但某些客户端、手机 App、Java 程序访问时报SSLHandshakeException或unable to find valid certification path to requested target。原因很简单服务器只发了自己的证书没有发中间 CA 证书。浏览器可以自动从系统信任库中找到上级 CA所以看起来没问题但有些客户端没有完整的中间证书缓存就验证失败了。解决办法是把中间证书和服务器证书按“服务器证书在前、中间证书在后”的顺序拼接成一个文件再放到ssl_certificate配置里。另外一类常见问题是自签名证书。测试环境图省事用一条命令生成自签名证书openssl req -x509 -newkey rsa:2048 -nodes -keyout example.key -out example.crt -days 365这个证书也能让 Nginx 跑起来 HTTPS但客户端访问时会报“此 CA 根目录证书不受信任”或self-signed certificate错误。如果你只是自己调试可以把自签名的example.crt导入操作系统或浏览器的受信任根证书列表这样本机访问就不报错了。如果给多个人用建议还是申请免费证书别用自签名省得每个人都要装证书。4.3 其他服务Java KeyStore、Tomcat、MySQL不少场景不是 Nginx而是 Java 应用或数据库需要证书。常见的做法是把pem和key转换成 PKCS12 格式再导入 Java KeyStore。以 Tomcat 配置 HTTPS 为例先准备 PKCS12 格式openssl pkcs12 -export -in example.pem -inkey example.key -out example.p12 -name tomcat -CAfile ca.pem -caname root然后在 Tomcat 的server.xml里配置Connector port8443 protocolorg.apache.coyote.http11.Http11NioProtocol maxThreads150 SSLEnabledtrue SSLHostConfig Certificate certificateKeystoreFile/path/to/example.p12 certificateKeystorePassword你的密码 typeRSA / /SSLHostConfig /ConnectorJava 客户端访问 HTTPS 时如果服务端证书是权威 CA 签发的JDK 自带信任库一般能直接信任如果用的是自签名或私有 CA 签发的证书需要在客户端指定信任库java -jar app.jar -Djavax.net.ssl.trustStore/path/to/truststore.jks -Djavax.net.ssl.trustStorePasswordchangeitMySQL 数据库开启 SSL 连接时也经常遇到[08001] SSL connection required, but not provided by server这种报错。这通常不是证书本身的问题而是客户端连接串里没有启用 SSL或者服务端配置了强制 SSL 而客户端没跟上。MySQL 连接串里加上useSSLtruerequireSSLtrue能解决一部分场景剩下的就要检查服务端ca.pem、server-cert.pem、server-key.pem是否齐全以及客户端是否信任了对应的 CA 证书。5. 高频报错排查从报错信息反推问题根因5.1 浏览器与客户端常见报错速查表我在实际项目里积累了一套“报错信息 → 根因 → 解决方案”的速查方法按高频程度排好遇到问题直接照着查报错信息关键词根因解决方案此 CA 根目录证书不受信任自签名证书或私有 CA 证书将 CA 证书导入系统/浏览器信任库或改用权威 CA 签发的免费证书curl: (60) ssl certificate problem证书链不完整/证书过期/域名不匹配检查服务器证书、中间证书链、证书绑定域名unable to get local issuer certificate缺少中间证书拼接完整证书链到pem文件SSL connection required, but not provided by server客户端未启用 SSL 或数据库 SSL 配置未生效连接串加useSSLtrue检查服务端 SSL 配置no required ssl certificate was sent客户端双向认证时未提供客户端证书配置客户端证书和信任库server 端设置clientAuthtrue时必须有客户端证书ssl recv / ssl shakehand服务器不支持 ssl服务端端口未配置证书、协议不匹配或未开启 TLS检查ssl_certificate配置、listen 443 ssl、安全组端口SSL peer handshake failed服务端与客户端 TLS 版本或密码套件不匹配调整ssl_protocols用openssl s_client测试握手详情ERR_CERT_COMMON_NAME_INVALID证书域名与实际访问域名不一致确保证书包含访问的域名多域名需要 SAN 支持certificate has expired证书已过期续期或重新申请5.2 客户端工具证书问题Charles/mitmproxy/JMeter做开发测试的人经常遇到 Charles、mitmproxy、JMeter 这些工具排查 HTTPS 流量时报一堆证书错误。这类问题本质都一样这些工具为了解密 HTTPS 流量会生成一个自己的根证书让客户端信任这个根证书然后动态签发每个域名的证书。如果你没有把工具的根证书安装到手机或浏览器的信任库就会一直报证书不受信任。一个经常被忽略的坑是手机上安装 Charles 证书后Android 7.0 以上的 App 默认不信任用户证书需要在 App 的网络安全配置里开启信任用户证书或者把证书装到系统证书目录需要 root。iOS 上需要在“设置 → 通用 → 关于本机 → 证书信任设置”里手动打开完全信任开关否则安装了也还是提示不受信任。JMeter 做 HTTPS 压测时如果被测服务用的是自签名证书或者不是常见 CA 签发JMeter 的 HTTP 请求里也要配置证书信任可以在 JVM 参数里指定信任库或者在 JMeter 的HTTP Request Sampler里勾选“Use preemptive authentication”并配置证书路径。最省事的方法是把服务端 CA 证书导入到 JVM 的cacerts信任库里keytool -import -alias example.ca -keystore cacerts -file ca.pem这里的cacerts默认密码是changeit导入后记得重启 JMeter。5.3 证书续期踩坑记录免费证书最大的麻烦是有效期短我身边不少朋友的站点都因为没注意续期导致线上访问突然报certificate has expired。整理几个我自己遇到过的续期典型坑第一个坑服务器时间漂移。证书的 validity 判断依据是服务器上的系统时间如果服务器时间快了或慢了几分钟会导致证书“看起来”还没过期但实际验证失败。排查方法很简单跑一下date -u和timedatectl status如果不是 UTC 时间且时间偏差明显装一下 NTP 同步服务ntpdate -u ntp.aliyun.com或者用 systemd-timesyncd 自动同步。第二个坑Certbot 的续期定时任务没生成。有时候安装 certbot 时用了 snap 或源码安装不会自动创建 cron 任务。检查方式certbot renew --dry-run systemctl list-timers | grep certbot如果 dry-run 报错或者没有定时器手动加一个 crontab0 3 * * * /usr/bin/certbot renew --quiet --renew-hook systemctl reload nginx第三个坑域名解析改了但证书没更新。如果你把站点从一个服务器迁移到另一台域名解析变了但原服务器上的 certbot 还在续期由于 ACME 验证会访问新解析地址也就是新服务器如果新服务器上没有对应的验证文件或 80 端口没开续期就会失败。此时要么在新服务器上重新证书申请要么确保旧服务器能处理验证请求直到证书续期成功。6. 免费证书运维的进阶建议6.1 证书监控提前发现而不是用户发现证书到期这种事情最怕的不是到期是没人知道哪天到期。我习惯给所有证书出口加一个简单的监控脚本每天检查一次到期时间到期前 15 天告警。用 OpenSSL 直接查远程证书到期时间echo | openssl s_client -connect example.com:443 -servername example.com 2/dev/null | openssl x509 -noout -dates输出里会看到notBefore和notAfter两个时间notAfter就是过期时间。配合脚本定期执行再接入邮件、钉钉或企业微信通知比任何平台自带的提醒都靠谱。如果你是运维也可以直接对接一些公开的证书透明度日志监控服务它们能监控域名的所有证书签发记录任何新证书签发、过期、被替换都能收到通知。这个对于域名多的情况尤其有用。6.2 从免费证书到更专业方案的演进路径免费证书虽然好用但有些场景确实不适合。比如你要给软件安装包做代码签名Windows 的代码签名证书、苹果开发者证书、应用到商店的签名等都是另一个体系不归属 SSL 证书但同样存在“免费 vs 付费”的取舍。代码签名证书如果泄露私钥后果比 SSL 证书严重得多这种场景建议直接用正规付费证书别折腾免费方案。再比如企业内部有几百台机器需要内部域名 HTTPS给每台机器都申请一个公网数字证书并不现实因为内部域名无法通过公网验证。更合理的做法是搭一个内部私有 CA统一签发内部证书并下发到各机器配置信任后内网访问就不会再出现证书告警。这个方向涉及 PKI 基础设施比单张证书复杂得多但从运维效率上看值得投入。从云厂商免费证书迁移到 Let’s Encrypt 自动化从 Let’s Encrypt 迁移到泛域名ACME 全自动其实是一个逐步加深掌控力的过程。一开始用控制台点几下无可厚非但如果长期管理三个以上的域名建议尽快把自动化做起来。证书管理的核心从来不是“申请某一刻”而是“长期、稳定、自动地保持可用状态”。7. 最后再分享一个我实际用下来的小技巧如果你白天在云厂商控制台申请了免费证书但发现 Nginx 部署后访问报错先别慌用一条命令快速定位 80% 的问题openssl s_client -connect 你的域名:443 -servername 你的域名观察输出里的Verify return code。0是最理想的状态unable to verify或certificate has expired会直接告诉你问题方向。这个命令比任何体检工具都直接明了我每次配置完证书都会跑一遍确认没问题才收工。如果你的服务在内网用内网 IP 代替域名同样能测。另外一个容易被忽略的细节证书文件路径要放在 Nginx 用户能读到的地方。pem和key文件如果放在/root/目录下Nginx 的 worker 进程很可能因为权限不足读不到私钥导致启动失败或 reload 失败。放到/etc/nginx/ssl/下并设置好权限chmod 600 *.key顺手避掉这个坑。证书这件事本质上就是“申请、部署、监控、续期”四个环节的循环。免费方案完全可以在生产环境稳定用只要把自动化续期和监控补上性价比远高于花钱买证书。希望这篇指南能帮你一次性跑通少走我当初走过的弯路。