企业官网建设流程全解析

很多朋友第一次给自己的站点配 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 免费证书的主要来源与选型思路

免费证书来源主流有三个方向：

第一类是 Let's Encrypt。这是目前全球使用量最大的免费证书机构，有成熟的开源客户端 Certbot，支持 HTTP 验证和 DNS 验证，可以签发单域名、多域名（SAN）和泛域名证书。它的最大优点是全自动续期、生态完善、所有主流服务器软件都有现成插件。缺点是证书有效期只有 90 天，必须靠定时任务自动续期，如果服务器没有外网访问权限或者域名解析不标准，自动续期容易失败。

第二类是云厂商的免费证书，比如阿里云、腾讯云都有每年一定数量的免费 DV 证书额度。申请流程在控制台里点几下就行，不需要在服务器上装客户端，审核也快，一般几分钟到几小时就发下来了。它的好处是申请门槛极低、适合不熟悉命令行的用户；缺点是不能泛域名、有效期一般也是一年或更短、续期麻烦（快到期的前一个月手动重新申请），而且不适用于某些特殊情况下的纯命令行服务器。

第三类是一些第三方免费 CA，比如 ZeroSSL、SSL.com 的免费套餐。这类更边缘一些，主要给那些不方便用 Let's Encrypt 自动化或者需要更灵活验证方式的场景。比如 ZeroSSL 提供 90 天免费证书，支持网页验证、DNS 验证和文件验证三种方式，但是它的免费套餐有证书数量限制，密钥和 CSR 可以在线生成，对比之下没有 Let's Encrypt 那么开箱即用。

以我的经验，如果是云服务器用户，优先用云厂商免费证书，因为下载下来格式齐全（Nginx、Apache、IIS、Tomcat 都有对应格式包），放服务器上就能用，省去自己处理证书链的麻烦。如果是自己管理一批服务器、追求自动化，直接上 Let's Encrypt + Certbot。两套方案不冲突，可以共存，比如主域名用云厂商证书、自动续期麻烦，那就写个脚本到期前重新申请；内部服务和测试环境统一用 Certbot 管理。

2. 申请前的准备：域名、解析与验证方式

2.1 证书验证的本质：证明域名是你的

很多人第一次申请证书时会卡在“验证”这一步，觉得莫名其妙。其实证书机构没那么关心你是谁，它只关心一件事：你是不是真的控制这个域名。这就好比你找居委会开证明，人家不看你长相，只看你户口本在不在这个地址上。

常见的验证方式有三种，我分别说一下适用场景：

DNS 验证：给你一个 TXT 记录值，让你加到域名的 DNS 解析里。证书机构会去查询这个 TXT 记录，查到了就认为你拥有域名。这种方式适合有域名解析控制台权限的任何人，不需要服务器在线，也是申请泛域名证书的唯一方式。

HTTP 文件验证：证书机构给你一个随机文件名和内容，让你放到网站根目录的/.well-known/pki-validation/路径下，然后它去访问http://你的域名/该路径来验证。这种方式要求你的服务器 80 端口可访问，并且域名已经解析到这台服务器。

邮件验证：证书机构给域名的 WHOIS 邮箱或常用管理员邮箱（比如admin@你的域名）发一封验证邮件，点一下链接就完成。这种方式现在比较少见，主流 CA 基本都用前两种。

我每次新建证书前都会先确认域名解析已经生效，用dig或在线工具查一下解析记录，再决定用哪种验证。申请 Let's Encrypt 的时候，如果域名刚好指向这台服务器，HTTP 验证很简单；如果域名解析在别的服务器上，用 DNS 验证更稳妥。云厂商控制台里申请证书时，如果你用它的 DNS 服务，通常能做到“自动添加解析记录”，连复制粘贴 TXT 记录的步骤都省了。

2.2 域名规划：单域名、多域名与泛域名的取舍

申请之前想清楚你到底需要哪种证书，可以省掉后面很多重复劳动。

单域名证书：只能保护一个域名，比如www.example.com。云厂商免费证书基本都是这种。适合只有一两个核心域名的场景。

多域名证书（SAN 证书）：一张证书可以同时保护多个完全不同的域名，比如a.com、b.com、www.c.com。Let's Encrypt 默认就支持在一张证书里加最多 100 个域名，只要这些域名都在你的控制下。这种适合域名不多但分散的场景。

泛域名证书：保护*.example.com下的所有二级域名。一旦你有很多子域名，比如api.、blog.、app.、m.，泛域名证书是最省心的方案，签一次全部覆盖。Let's Encrypt 支持签发泛域名，但只能用 DNS 验证。云厂商免费证书基本不提供泛域名，这也是很多人从云厂商转向 Let's Encrypt 的原因。

做技术选型时我有一个建议：个人项目优先单域名+脚本自动续期；公司内部有多个子域名的，直接上 Let's Encrypt 泛域名证书；如果项目域名就三五个且不常变，可以用多域名证书把全部塞进一张里，省得管理多个文件。

2.3 服务器环境准备：Nginx 和端口放行

证书申请下来最终要部署到服务器上，所以服务器环境最好提前准备好。这里以 Nginx 为例，先把必要的环境检查做一遍：

nginx -v openssl version

如果 Nginx 没装，Ubuntu/Debian 系统可以用apt install nginx，CentOS/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 Let's Encrypt 使用 Certbot 申请与自动续期

如果你自己有独立的服务器，我更推荐用 Certbot 直接申请 Let's Encrypt 证书。它的工作原理是：Certbot 在服务器上临时启动一个验证服务，Let's 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-run

Certbot 的续期机制是：证书到期前 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文件必须包含完整证书链。怎么验证呢？用 OpenSSL：

openssl 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 port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true"> <SSLHostConfig> <Certificate certificateKeystoreFile="/path/to/example.p12" certificateKeystorePassword="你的密码" type="RSA" /> </SSLHostConfig> </Connector>

Java 客户端访问 HTTPS 时，如果服务端证书是权威 CA 签发的，JDK 自带信任库一般能直接信任；如果用的是自签名或私有 CA 签发的证书，需要在客户端指定信任库：

java -jar app.jar -Djavax.net.ssl.trustStore=/path/to/truststore.jks -Djavax.net.ssl.trustStorePassword=changeit

MySQL 数据库开启 SSL 连接时，也经常遇到[08001] SSL connection required, but not provided by server这种报错。这通常不是证书本身的问题，而是客户端连接串里没有启用 SSL，或者服务端配置了强制 SSL 而客户端没跟上。MySQL 连接串里加上useSSL=true&requireSSL=true能解决一部分场景，剩下的就要检查服务端ca.pem、server-cert.pem、server-key.pem是否齐全，以及客户端是否信任了对应的 CA 证书。

5. 高频报错排查：从报错信息反推问题根因

5.1 浏览器与客户端常见报错速查表

我在实际项目里积累了一套“报错信息 → 根因 → 解决方案”的速查方法，按高频程度排好，遇到问题直接照着查：

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 报错或者没有定时器，手动加一个 crontab：

0 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，顺手避掉这个坑。

证书这件事，本质上就是“申请、部署、监控、续期”四个环节的循环。免费方案完全可以在生产环境稳定用，只要把自动化续期和监控补上，性价比远高于花钱买证书。希望这篇指南能帮你一次性跑通，少走我当初走过的弯路。