企业官网建设流程全解析

又是熟悉的报错：“此站点无法安全地连接，这可能是因为该站点使用过期的或不安全的TLS安全设置。”坐到对面的同事已经把浏览器换了三个，依然打不开内网系统。实际上，我敢说大部分所谓的SSL/TLS问题，到最后都绕不开三件事：证书链不对、协议版本太老、加密套件不匹配。今天这篇博客，我就把自己折腾SSL/TLS和HTTPS这些年的经验，从握手原理到证书生成，再到各种诡异报错的排查，一次性讲明白。

无论你是后端开发、运维、测试，还是刚入门的学生，只要你的日常和Web接口、数据库连接、甚至单片机设备通信沾边，这篇内容都值得看。它不会只停留在“HTTPS比HTTP安全”这种正确但没用的层面，而是会说明白握手过程里到底交换了什么、证书是怎么被信任的、常见报错为什么会发生。

1. SSL/TLS到底是什么？为什么我们离不开它

1.1 从HTTP明文抓包说起：你的密码等于在裸奔

HTTP明文传输就像把话写在明信片上寄出去，中途经过的每个邮局都能看到内容。你输入的用户名、密码、Cookie、请求参数，这些数据在网络链路上都是以明文方式在跑，只要有人在路由节点抓包，信息基本等于直接曝光。

用Wireshark随便抓一个HTTP请求，比如POST登录接口，直接就能在“Follow HTTP Stream”里看到类似这样的内容：

POST /login HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded username=admin&password=123456

注意，我说的是“https明文捕获”场景里最基础的原理。很多人以为自己的网站不涉及钱就没有安全问题，实际上普通登录页面泄露账号密码，后续可能引发撞库、爬虫盗用会话等一系列连锁反应。

SSL/TLS做的事情，就是给明信片套上加密信封。这里的核心思路是混合加密：用非对称加密完成密钥协商，用对称加密完成实际数据加密。为什么不用纯非对称加密？因为性能太差，RSA解密一次就要做模幂运算，如果每传一个数据包都做一遍，服务器CPU会直接飙红。所以TLS设计成用非对称加密保护一个临时生成的对称密钥，后续数据用这个对称密钥来加密，这样既安全又高效。

1.2 SSL和TLS的版本演进：一堆历史包袱

很多初学者会问：SSL和TLS到底是不是同一个东西？简单说，TLS是SSL的后继者。SSL由Netscape公司提出，发展到3.0版本后，IETF接手并进行标准化，改名为TLS 1.0。所以你现在经常看到“SSL/TLS”连写，其实就是指同一个安全通道体系。

版本演进史大概是这样：

我为什么专门列这个表？因为热词里出现“tls 1.0/1.1”，而且很多浏览器还会报“不安全的TLS安全设置”。说白了，TLS 1.0和1.1已经属于上个时代的产物，主流浏览器在2020年后陆续默认禁止这两个版本。如果你维护的老系统还只支持这两个版本，用户访问时就会出现开头那种报错，或者直接显示“此站点不安全”。

另外，基于SSLv3和旧版加密套件产生的漏洞，比如CVE-2016-2183，也是安全扫描工具喜欢报的问题。这些问题不是“你网站被入侵了”，而是“你的加密配置太弱，存在被破解的理论风险”。后面第5节我会专门讲怎么修。

2. HTTPS握手过程拆解：一次神秘的钥匙交换

2.1 一次TLS 1.2握手的完整过程

我看过太多人把“HTTPS握手”解释成“客户端和服务器交换一个密钥”，这其实省略了最关键的几步。以最常见的TLS 1.2握手为例，整个过程大致是这样：

第一步，客户端发起ClientHello。客户端会带上自己支持的TLS版本列表、加密套件列表（Cipher Suites）、一个随机数Client Random，以及可选的SNI扩展——就是告诉服务器“我要访问的是example.com，而不是那个IP地址”。

第二步，服务器回应ServerHello。服务端从客户端支持的列表中挑选一个双方都能用的加密套件，比如ECDHE-RSA-AES128-GCM-SHA256，同时返回服务器随机数Server Random。随后服务器还会发送证书（Certificate消息），如果要求客户端认证，还会发送CertificateRequest。

第三步，证书校验与密钥交换。客户端收到证书后，要验证这个证书是否可信。验证通过后，如果使用的是ECDHE密钥交换算法，服务器会发送ServerKeyExchange，携带ECDH参数和自己的签名；客户端也根据这些参数算出预主密钥（Pre-Master Secret）。

第四步，生成会话密钥。客户端和服务器分别基于Client Random、Server Random和Pre-Master Secret，通过PRF（伪随机函数）派生出一组会话密钥。注意，这个过程中客户端还会发送一个ClientKeyExchange消息，用服务器的公钥加密预主密钥（如果使用RSA交换），或者直接携带ECDHE的参数（如果使用ECDHE交换）。

第五步，ChangeCipherSpec和Finished。双方都宣称“我开始用加密通信了”，然后发送Finished消息，这条消息是用协商好的会话密钥加密的，里面包含之前所有握手消息的摘要，用来防止握手消息被篡改。

这中间最关键的概念是前向保密。如果你用RSA做密钥交换，服务器私钥一旦泄露，历史上录制的加密流量都能被解密。而ECDHE是每次会话生成临时的ECDH密钥对，会话结束后临时密钥就销毁了，即使服务器私钥泄露，也无法解出历史会话内容。这也是现代安全基线要求用ECDHE而不是普通RSA交换的原因。

2.2 证书信任链：为什么浏览器会相信这个证书

服务器在握手中发送的Certificate，本质上是一个数字身份证明。但浏览器凭什么相信它？这就涉及到信任链。

证书是由CA（证书颁发机构）签发的。CA的根证书预埋在操作系统或浏览器里，我们叫它Root CA。服务器证书不是直接由根证书签发的，而是由中间CA签发，中间CA再由根CA签发，形成一条链：服务器证书 -> 中间证书 -> 根证书。

举个例子，你用阿里云申请一张免费SSL证书，下载下来通常会有三个文件：

• server.crt：你的服务器证书
• server.key：你的私钥，放在服务器上
• ca.crt或中间证书：阿里云提供的中间CA证书

在Nginx上你又经常看到配置的是fullchain.crt，这个文件就是把服务器证书和中间证书拼接在一起的结果。如果漏了中间证书，浏览器会用系统根证书去验证服务器证书，发现签发者不受信任，就会报错。

热词里有一条很典型：curl: (60) ssl certificate problem: unable to get local issuer certificate。这个报错翻译过来就是“无法获取本地签发者证书”。常见原因是服务器返回的证书链不完整，或者你测试时没有把自签CA加入到系统信任库。后面第3节我会给出具体修复方案。

2.3 TLS 1.3的变化：更快也更安全

到了TLS 1.3，握手流程做了大幅优化。它默认使用ECDHE或者DHE进行密钥交换，砍掉了一批过时和不安全的加密套件。而且把通常从1.3个RTT缩短到1个RTT，也就是说，客户端发出ClientHello时就可以同时发送自己的密钥共享参数，服务器收到后直接回应ServerHello和证书，双方可以立刻算出会话密钥。

更极端的是会话恢复机制。TLS 1.3支持0-RTT恢复：如果之前已经建立过会话，客户端可以在TLS握手中的第一条消息里直接携带应用数据，服务器校验PSK成功后立即响应。这个功能可以显著降低HTTPS访问延迟，但是有重放攻击风险，所以一般只建议用在GET等幂等请求上，不要用在POST写操作上。

我在实际压测中发现，同样一张页面，从TLS 1.2切到TLS 1.3，握手时间能少一半多。如果你还没开启TLS 1.3，可以看看服务器端口是否兼容，主流的Nginx 1.19+、OpenSSL 1.1.1以上都已支持。

3. 证书生成与配置实战：从私钥到完整证书链

3.1 OpenSSL生成带SAN的自签名证书

很多内网系统没有外网域名，但开发、测试又需要HTTPS，最快速的办法就是用OpenSSL生成自签名证书。这里有个坑：Chrome从2018年起严格检查证书的SAN（Subject Alternative Name，主题备用名称），如果你生成证书时只写CommonName，不写DNS或IP的SAN，浏览器会直接报“NET::ERR_CERT_COMMON_NAME_INVALID”。所以网上那些老教程里openssl req -new -x509 -keyout key.pem -out cert.pem -days 365一行命令生成的证书，在现代浏览器里基本不能直接用。

正确的做法是准备一个配置文件，比如san.cnf：

[req] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [req_distinguished_name] C = CN CN = example.com [v3_req] subjectAltName = @alt_names [alt_names] DNS.1 = example.com DNS.2 = www.example.com IP.1 = 192.168.1.100 IP.2 = 127.0.0.1

然后生成私钥和证书签名请求：

openssl req -newkey rsa:2048 -nodes -keyout server.key -out server.csr -config san.cnf

接着用自建的CA证书给这个CSR签名（也可以直接自签名）：

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out server.crt -days 365 -extensions v3_req -extfile san.cnf

这样生成的证书就带了多个域名和IP地址。热词里提到的“多域名ssl证书生成”，本质上就是分别创建SAN条目。如果是一家正规的云厂商证书，也能在申请时填写多个域名，生成多域名证书。

3.2 证书链不完整：unable to get local issuer certificate

用自签名证书时，最容易踩的坑是“证书不完整”。很多同学直接把server.crt扔到Nginx配置里：

server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; }

然后把ca.crt放到服务器上就不管了。用浏览器访问时，可能没问题——因为你可以手动信任CA根证书；但其他设备或工具访问时，比如curl、Android App，由于它们没有安装你的这个根证书，就会报unable to get local issuer certificate。

正确做法是把服务器证书和中间CA证书拼成一个文件：

cat server.crt ca.crt > fullchain.crt

然后Nginx里配置：

ssl_certificate /etc/nginx/ssl/fullchain.crt; ssl_certificate_key /etc/nginx/ssl/server.key;

如果服务器证书是由某公共CA签发的，这个文件必须包含所有中间证书，直到但不包括根证书。可以去https://whatsmychaincert.com/这种工具帮助检查。实在不行，用命令看证书链：

openssl s_client -connect example.com:443 -showcerts -servername example.com

如果返回里能看到verify return:1，说明证书链没有问题。

3.3 证书过期与自动续期：别再手动续费了

很多系统上线后，隔了一段时间突然所有客户端都报“证书过期”，检查一看，证书确实已经过期一两天。热词里就有“the tls certificates for the following protocols have expired”，还有个“阿里云ssl证书免费续期”。

我强烈建议把证书续期做成自动化。对小网站和测试环境，用ACME客户端（比如certbot）自动申请Let's Encrypt证书，并配置定时renew，这样证书快过期时它会自动续期。生产环境如果因为合规原因必须用收费证书，也可以在云厂商控制台开启“证书到期提醒”，一般提前30天就会发短信。

在证书到期前，最好自己先检查一遍：

openssl x509 -in server.crt -noout -enddate

输出类似：

notAfter=Sep 25 23:59:59 2025 GMT

另外，如果证书还没过期但客户端报“证书不受信任”，就要回到第3.2节，先看证书链，再看CA根证书是否正确安装。

4. 典型客户端集成场景的SSL/TLS实战

4.1 Java NIO SSL客户端：自己控制握手

Java里用标准HttpURLConnection或HttpClient往往帮你处理了证书验证，但如果是自己做NIO通信，比如基于Netty或者原生SocketChannel，就绕不开SSLEngine。很多人在这里报错，要么是没配置TrustStore，要么是手握证书但没设置对。

一个常见需求是客户端访问某个HTTPS接口，服务端要求双向认证（mTLS），此时你需要在启动参数里指定：

java -Djavax.net.ssl.keyStore=client.p12 \ -Djavax.net.ssl.keyStorePassword=123456 \ -Djavax.net.ssl.trustStore=truststore.jks \ -Djavax.net.ssl.trustStorePassword=123456 \ -jar app.jar

如果是用Netty，可以在SslContextBuilder里配置：

SslContext sslCtx = SslContextBuilder.forClient() .keyManager(KeyManagerFactory.getInstance(keyStore, password)) .trustManager(TrustManagerFactory.getInstance(trustStore)) .protocols("TLSv1.2", "TLSv1.3") .build();

4.2 STM32 MQTT的TLS加密通信

嵌入式设备的HTTPS/MQTT TLS也是重灾区。很多物联网项目中，设备需要把传感器数据通过MQTT协议上云，如果明文传输，数据包在WiFi环境下一抓一个准。热词“stm32 mqtt tls加密通信”说的就是这个场景。

在STM32这类MCU上，常配合mbedTLS（现在叫Mbed TLS，由Trusted Firmware维护）来做TLS。基本流程是：

1. 初始化CTR-DRBG随机数生成器，这是TLS握手的随机源。
2. 解析CA证书，用mbedtls_x509_crt_parse把服务器的CA证书加载到内存。
3. 配置SSL上下文：设置传输回调函数（基于你的TCP socket）、证书校验回调、是否启用双向认证。
4. 建立TCP连接后，调用mbedtls_ssl_handshake完成握手。
5. 握手成功后，通过mbedtls_ssl_read和mbedtls_ssl_write读写数据。

这里要注意的是内存，TLS握手需要一大块缓冲区，默认配置可能吃掉几十KB RAM，对STM32F103这种只有64KB SRAM的芯片来说比较紧张。可以用MBEDTLS_SSL_MAX_CONTENT_LEN调小，或使用PSK（预共享密钥）模式，tls + psk就是这个玩法，不需要证书，只需要预置密钥，握手更快、内存更省，适合资源受限的小终端。

4.3 SQL Server连接报SSL错误的解决办法

有一个报错让很多人摸不着头脑：

驱动程序无法通过使用安全套接字层(ssl)加密与 sql server 建立安全连接。 错误: "[08001] ssl connection required, but not provided by server."

这个报错的意思是：客户端驱动程序默认要强制加密连接，但SQL Server服务端没有启用“加密连接”选项，或者没有正确安装证书。SQL Server默认情况下，如果服务端没有配置证书，客户端强制加密时就会失败。

解决办法有两种。

第一，在SQL Server配置管理器里，打开“SQL Server网络配置” -> “协议” -> 右键属性，把“Force Encryption”设为“是”，然后在“证书”页选择一个服务器证书，重启SQL Server服务。

第二，如果只是开发环境，可以在JDBC连接串里暂时关闭证书校验：

jdbc:sqlserver://host:1433;databaseName=dbname;encrypt=true;trustServerCertificate=true;

trustServerCertificate=true的作用是跳过客户端对服务端证书的校验。注意这个参数只适合测试环境，生产环境等于临时给信任链放行，不符合安全基线。

4.4 JMeter录制HTTPS脚本的证书配置

做性能测试的同学几乎都会用JMeter录制脚本，但第一次录制HTTPS请求时会发现，浏览器里能打开页面，JMeter却只录到CONNECT请求，或者直接报SSL异常。这是因为HTTPS是加密的，JMeter的HTTP代理服务器必须生成一个中间人证书来解密流量。

JMeter其实自带了这个功能。打开JMeter后，添加“线程组” -> “HTTP(S)测试脚本记录器”，默认端口8888，然后先点击界面上的“Options” -> “SSL Manager”，或者在系统提示时导入JMeter/bin目录下的ApacheJMeterTemporaryRootCA.crt。把这证书导入到浏览器或操作系统的受信任根证书颁发机构里，再设置HTTP代理为127.0.0.1:8888，就可以录制到HTTPS请求了。

录制完成后，我习惯把根证书从系统信任库删掉。因为测试结束后，如果不删除JMeter根证书，黑客理论上可以利用这个根证书伪造你的HTTPS站点流量，这就是中间人攻击的基础。

5. 高频报错排查与安全加固实录

5.1 “无法安全地连接到此页面”出在哪？

开头提到的“无法安全地连接到此页面 这可能是因为该站点使用过期的或不安全的 tls 安全设置”，在浏览器里其实是“ERR_SSL_VERSION_OR_CIPHER_MISMATCH”。这个报错很直白：客户端和服务器没有协商出一个双方都支持的TLS版本和加密套件。

最常见的原因是服务器端只启用了TLS 1.0或TLS 1.1，而现代浏览器已经默认禁用这些老版本。用命令可以快速确认服务器支持的协议：

openssl s_client -connect example.com:443 -tls1_0 </dev/null openssl s_client -connect example.com:443 -tls1_2 </dev/null openssl s_client -connect example.com:443 -tls1_3 </dev/null

如果只前两个成功，后面两个失败，说明服务端需要升级协议配置。在Nginx里推荐这样设置：

ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5:!3DES; ssl_prefer_server_ciphers on;

配置完记得nginx -t测试，然后reload。改完后再用openssl s_client检查，看到New, TLSv1.3或者TLSv1.2版本，才算修好。

5.2 SSL recv报错：服务器真的不支持SSL吗？

热词里有一条：

错误信息: ssl recv :服务器不支持ssl,请检查服务器配置, errorcode: 1

这类报错常见于企业IM、邮件客户端、老版本FTP客户端。它表面意思是指服务器不支持SSL，但大部分时候是“你连的端口或协议用错了”。比如你用一个HTTPS端口去连接普通HTTP服务，或者用自有客户端去连接一个没有启用TLS的端口，服务端自然返回不了正确的TLS握手包。

排查步骤我一般是这样：

先用openssl s_client -connect host:port试一下，如果能看到CONNECTED(00000003)和证书信息，说明端口确实是TLS端口；如果卡在那里没有任何输出，或者报SSL routines:ssl3_read_bytes:tlsv1 alert protocol version，说明端口协议不对，或服务端不支持该TLS版本。

还有一种情况是服务端配置了“仅在特定域名下启用TLS”，但你用IP访问，导致SNI不匹配。这时候指定-servername参数再试：

openssl s_client -connect 192.168.1.10:443 -servername www.example.com

如果服务端确实需要TLS但你又改不了，也可以在客户端代码里调整SocketFactory兼容策略，问题是治标不治本，最终还是要服务端把协议配正确。

5.3 双向认证：no required ssl certificate was sent

当服务端开启了双向TLS认证（mTLS，常见于企业接口、支付网关），客户端必须提供自己的客户端证书，否则服务端返回的握手消息里会带一个CertificateRequest，而客户端没发证书，就会出现经典报错：

no required ssl certificate was sent

这个报错翻译过来就是“服务器要求客户端证书，但客户端一个都没给”。根因有几种：

• 客户端根本没导入客户端证书和私钥。
• 客户端导入了证书，但程序没有指定使用哪个KeyManager。
• 服务端配置要求verify_client on，但客户端忽略了这个要求。
• 证书不匹配：服务端配置的CA没下发过对应客户端证书。

解决思路是：先在服务端或测试工具里确认握手是否要求客户端证书。用openssl做双向认证时，客户端要同时指定这一串证书：

openssl s_client -connect example.com:443 \ -cert client.crt \ -key client.key \ -CAfile ca.crt

如果这样能握手成功，再回到Java或App代码里检查KeyStore配置。在Nginx里对应的参数是：

ssl_verify_client on; ssl_client_certificate /etc/nginx/ssl/ca.crt;

5.4 CVE-2016-2183漏洞：禁用3DES加密套件

安全扫描报告中经常出现这样的条目：

SSL/TLS协议信息泄露漏洞(CVE-2016-2183)【原理扫描】

CVE-2016-2183就是针对密码块链（CBC）模式下3DES加密算法的攻击面。扫描器发现服务端允许使用DES-CBC3-SHA这类套件，就会报这个漏洞。因为3DES只有112位有效安全强度，而且SWEET32攻击能在较短时间内恢复明文。

修复方式很简单：把3DES从加密套件列表里移除。Nginx里可以这样改：

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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_protocols TLSv1.2 TLSv1.3;

Apache则用：

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:... -3DES

改完以后可以用在线扫描或者sslscan工具重新检测，看到“No 3DES suite”就说明修复到位了。

5.5 排查SSL/TLS问题的三板斧

最后分享一套我治SSL/TLS问题的排查流程，碰到任何连接异常都先按这个走，能少走很多弯路。

第一板斧是看证书。用openssl s_client -connect host:port -servername host查看服务器返回的证书链，重点看verify return code。如果不为0，直接google对应错误码，90%是证书链或主机名不匹配。

第二板斧是看协议和加密套件。用openssl s_client -tls1_2和-tls1_3分别测，再用openssl ciphers -v 'HIGH:!aNULL:!3DES'看看本地支持的套件。如果服务端套件和客户端套件没有交集，就会报 mismatch 之类的错。

第三板斧是抓包看握手。如果需要看更细的细节，或者怀疑是代码层面的问题，就用Wireshark抓TLS ClientHello和ServerHello，快速判断哪一步断掉。确认TLS记录层版本、随机数、证书消息、密钥交换消息，基本能定位到具体环节。

这个排查顺序我踩过无数次坑后才总结出来：不要一头扎进代码里找Bug，很大概率是你的Nginx没有把证书链配好，或者防火墙把端口的TLS流量给拦了。从底层开始排查，效率最高。

我个人在实际操作中的体会是，SSL/TLS这事，看着复杂，其实核心就三块：密码学基础、证书信任链、协议版本协商。先把这三块搞明白，再遇到任何和HTTPS、SSL连接有关的报错，你心里都会有个排查地图，不至于像无头苍蝇一样到处试。上面提到的OpenSSL命令和Nginx参数，我建议你每一条都在测试环境亲手跑一遍，跑通之后就知道怎么对照生产环境了。最后再分享一个小技巧：任何证书或协议配置改动后，都先用openssl s_client验证一下再告诉别人“修好了”，这是运维和开发之间最不容易产生误解的交流方式。