tls

当我们讨论 HTTPS 安全性时，证书吊销检查是一个常被忽视但至关重要的环节。传统的 OCSP（Online Certificate Status Protocol）存在隐私和性能问题，Mozilla 提出的 CRLite 提供了一种更优的解决方案。本文将深入探讨 CRLite 的设计原理、与 OCSP 的对比，以及如何在实际环境中应用。 传统 OCSP 的问题 在了解 CRLite 之前，我们先回顾一下传统 OCSP 面临的挑战： 1. 隐私泄露 OCSP 请求会直接向 CA 的 OCSP 服务器发送请求，这会暴露用户的浏览行为。攻击者可以通过监控 OCSP 请求来确定用户正在访问哪些网站。 1 2 # 模拟 OCSP 请求 openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 10 "OCSP response" 2. 性能瓶颈 每次建立 HTTPS 连接时，客户端都需要额外查询 OCSP 服务器，这增加了握手延迟。如果 OCSP 服务器响应缓慢，会直接影响用户体验。 1 2 3 # 测试 OCSP 响应状态（使用 timeout 防止卡住） timeout 5 openssl s_client -connect ocsp....

在生产环境中配置 HTTPS 时，经常会遇到各种问题。本文总结 Nginx SSL 配置中的常见错误及其排查方法，帮助你快速定位和解决问题。 1. 证书链顺序错误 常见症状 浏览器显示证书链不完整或提示「此证书链不受信任」： 1 2 # 使用 openssl s_client 查看证书链 echo | openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E "subject=|issuer=" 问题原因 Nginx 配置的证书文件只包含服务器证书，没有包含中间证书（Intermediate Certificate）。 解决方法 将证书链按正确顺序拼接：服务器证书 → 中间证书 → 根证书（可选）。 1 2 3 4 # 正确的证书链顺序 cat server.crt > nginx-ssl.crt cat intermediate.crt >> nginx-ssl.crt # 根证书通常不需要添加 Nginx 配置： 1 2 3 4 5 6 7 8 9 server { listen 443 ssl; server_name example....

TLS 1.3 在握手效率和安全机制上做了重大改进。除了优化的握手流程外，协议还定义了一系列 Post-Handshake 消息，在握手完成后处理会话恢复、密钥更新等重要功能。理解这些消息对于深入掌握 TLS 1.3 至关重要。 什么是 Post-Handshake 消息？ 在 TLS 1.3 中，握手完成后双方进入加密通信阶段。此时协议定义了一组特殊消息，用于处理握手后的事务： NewSessionTicket：发送会话票据，用于后续会话恢复 KeyUpdate：更新加密密钥，保持前向安全性 CertificateRequest：请求客户端证书（握手后认证） Certificate：提供客户端证书 CertificateVerify：验证客户端证书 这些消息与主握手流程独立，通过独立的加密通道传输。 NewSessionTicket（会话票据） 原理 NewSessionTicket 是 TLS 1.3 会话恢复机制的核心。当客户端和服务器完成完整握手后，服务器可以发送一个加密的会话票据给客户端。下次连接时，客户端可以使用这个票据恢复会话，无需完整握手，从而实现 1-RTT 甚至 0-RTT 的快速连接。 工作流程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 完整握手： 客户端 服务器 | | |--------------- ClientHello ----------------->| | (附 session_id / session_ticket) | |<-------------- ServerHello ------------------| |<-------------- Certificate ------------------| |<-------------- CertificateVerify ------------| |<---------------- Finished -------------------| |--------------- Finished -------------------->| | | |================ 加密通道 ====================| | | |<------------- NewSessionTicket -------------| | | 快速恢复（0-RTT）： 客户端 服务器 | | |-------- ClientHello + EarlyData + Ticket -->| |<-------- ServerHello + EarlyData ------------| |<---------------- Finished -------------------| |--------------- Finished -------------------->| | | 实际验证 使用 OpenSSL 查看 TLS 1....

在使用 Diffie-Hellman（DH）密钥交换实现前向保密（PFS）时，DH 参数是必不可少的基础组件。本文详细介绍 OpenSSL dhparam 命令的用法，帮助你生成、验证和管理 DH 参数。 什么是 DH 参数？ DH 密钥交换的安全性依赖于两个数学参数：大素数 P 和生成元 G。这两个参数构成 DH 参数组，决定了密钥交换的安全强度。 P（素数）：一个安全的大素数，作为模数 G（生成元）：一个整数，用于生成密钥交换所需的数学运算 基本用法 生成 DH 参数 生成指定位数的 DH 参数是最常用的操作： 1 2 # 生成 2048 位 DH 参数 openssl dhparam -out dhparam.pem 2048 这个命令会生成一个 2048 位的安全素数参数组。生成过程可能需要一些时间，因为需要找到合适的素数。 使用不同生成元 默认情况下，OpenSSL 使用生成元 2。你可以指定其他生成元（2、3 或 5）： 1 2 3 4 5 6 7 8 # 使用生成元 2（默认） openssl dhparam -out dhparam.pem -2 2048 # 使用生成元 3 openssl dhparam -out dhparam....

国密 SM2 算法是中国国家密码管理局发布的椭圆曲线公钥密码算法，相比传统的 RSA 和国际通用 ECDSA 曲线，SM2 在国内有着特殊的应用场景和政策要求。本文详细介绍 SM2 证书的生成、验证和部署。 SM2 证书与 RSA/ECDSA 证书的区别 算法基础 特性 RSA ECDSA (secp256r1) SM2 密钥长度 2048/4096 bit 256 bit 256 bit 曲线类型 离散对数 椭圆曲线 椭圆曲线 (SM2 曲线) 签名算法 RSA + SHA-256 ECDSA + SHA-256 SM2 + SM3 国际认可 广泛认可 广泛认可 中国国密标准 性能 较慢 较快 与 secp256r1 相当 关键差异 签名算法：SM2 证书使用 SM3 哈希算法进行签名，而不是 SHA-256 曲线参数：SM2 使用特定的椭圆曲线参数（国家密码管理局指定） 兼容性：国际浏览器和设备默认不支持 SM2 证书，需要国密浏览器或支持国密的组件 生成 SM2 证书 环境要求 确保系统安装的是 OpenSSL 3....

详解 TLS 会话票据（Session Ticket）的工作原理，为什么需要定期轮换密钥，以及如何在 Nginx、Apache 中配置安全的密钥轮换策略。

TLS 指纹识别是一种通过分析 TLS 握手过程中的参数来识别客户端或服务器的技术。与传统的 IP 地址或端口识别不同，TLS 指纹更加稳定，即使攻击者更换 IP 地址，也能通过指纹识别出来。 什么是 TLS 指纹？ TLS 指纹（TLS Fingerprint）是基于 TLS 握手过程中的特定参数生成的唯一标识。这些参数包括： TLS 版本：如 TLS 1.2、TLS 1.3 密码套件列表：客户端支持的密码套件顺序 扩展列表：支持 TLS 扩展 支持的群（TLS 1.3）或椭圆曲线（TLS 1.2） 签名算法 不同的 TLS 库和应用程序在握手时会发送不同的参数组合，这使得它们可以被识别。 JA3 与 JA4 的区别 JA3 JA3 是由 Salesforce 开发的 TLS 指纹方法，格式为： 1 TLSVersion,CipherSuites,Extensions,EllipticCurves,SignatureAlgorithms 示例： 1 771,4865-4866-4867-49195-49199-49171-49172-156-157-47-53,0-23-65281-16-22-35,29-23-24,0 然后对整个字符串进行 MD5 哈希，生成 32 字符的十六进制指纹： 1 1ab209a4577159577b15884bde700eaf JA4 JA4 是较新的指纹方法，由 Salesforce 在 2024 年推出，格式更加详细： 1 2 3 4 5 6 JA4<a><b><c><d> - a: TLS 版本 (如 13 表示 TLS 1....

在调试 TLS 配置或测试客户端证书时，我们经常需要一个临时的 HTTPS 服务器。OpenSSL 提供的 s_server 命令可以快速启动一个测试 TLS 服务器，无需复杂的配置。 本文将详细介绍 s_server 的各种用法，帮助你在调试和测试中提高效率。 快速启动 HTTPS 服务器 最简单的用法 只需要指定证书和私钥文件，即可启动一个 HTTPS 服务器： 1 openssl s_server -cert server.crt -key server.key -www 启动后，访问 https://localhost:4433/ 会看到一个状态页面，显示服务器支持的 TLS 版本和密码套件。 如果你没有现成的证书，可以快速生成一个自签名证书： 1 2 # 生成测试用证书 openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes -subj "/CN=Test Server" 常用端口和地址 默认端口是 4433。如果需要使用标准 HTTPS 端口 443，需要 root 权限： 1 2 3 4 5 # 监听 443 端口（需要 root 权限） openssl s_server -cert server....

深入解析 ACME 协议工作原理，详解 Let’s Encrypt 免费证书申请与 Certbot 自动续期配置，实现 HTTPS 证书自动化管理。

什么是 PKCS#12？ PKCS#12（也称为 PFX）是公钥密码学标准之一，定义了一种用于存储多个密码学对象的文件格式。在实际应用中，PKCS#12 文件通常用于： 打包服务器证书和私钥 包含证书链（CA 证书） 在不同系统之间迁移证书和私钥 与 PEM 格式相比，PKCS#12 将证书、私钥和证书链打包成单个二进制文件，并支持加密保护。 基本用法 从私钥和证书创建 PKCS#12 最常见的用法是将私钥和服务器证书打包成 PKCS#12 文件： 1 2 3 4 5 6 openssl pkcs12 -export \ -out server.p12 \ -inkey server.key \ -in server.crt \ -name "Server Certificate" \ -passout pass:changeit 参数说明： -export：创建 PKCS#12 文件 -out server.p12：输出文件名 -inkey server.key：输入的私钥文件 -in server.crt：输入的证书文件 -name "Server Certificate"：证书的友好名称（可选） -passout pass:changeit：导出密码 执行后会在当前目录生成 server.p12 文件。 查看 PKCS#12 文件内容 创建后可以使用以下命令查看文件信息： 1 openssl pkcs12 -in server....