tls

证书指纹（Certificate Fingerprint，也称 Thumbprint）是证书的唯一标识符。通过对证书内容进行哈希计算得出，广泛应用于证书 pinning、自动化监控、证书比对等场景。本文详细介绍 OpenSSL 计算证书指纹的各种方法。 什么是证书指纹？ 证书指纹是对整个证书 DER 编码内容进行哈希计算的结果。常见哈希算法： SHA-1：兼容性较好，但因安全原因已不推荐 SHA-256：目前推荐的主要算法 MD5：仅用于兼容旧系统，强烈不推荐 基本计算方法 使用 x509 命令 1 2 3 4 5 6 7 8 # SHA-256 指纹（推荐） openssl x509 -noout -fingerprint -sha256 -in certificate.crt # SHA-1 指纹 openssl x509 -noout -fingerprint -sha1 -in certificate.crt # MD5 指纹（不推荐） openssl x509 -noout -fingerprint -md5 -in certificate.crt 实际输出示例： 1 sha256 Fingerprint=71:DA:A0:3E:9E:A4:A8:C3:B0:D8:E9:2B:FD:EB:81:77:71:39:82:93:3E:C6:E1:21:7A:C1:DC:C0:D1:C0:78:F2 使用 dgst 命令 1 2 # 使用 dgst 计算 SHA-256 指纹 openssl dgst -sha256 certificate....

PEM（Privacy-Enhanced Mail）是 OpenSSL 和大多数 Linux/Unix 系统中最常用的证书和私钥格式。理解 PEM 的内部结构有助于排查格式转换问题、编写自动化脚本，以及深入理解 PKI 工作原理。 PEM 格式概述 PEM 是一种基于 Base64 编码的格式，用于存储DER编码的二进制数据。其核心特点： 文本友好：内容为可打印的 ASCII 字符，便于复制粘贴 结构化：使用 -----BEGIN xxx----- 和 -----END xxx----- 标记包裹 Base64 编码：将 DER 二进制数据转换为 ASCII 字符 PEM 文件结构 典型的 PEM 文件结构如下： 1 2 3 4 -----BEGIN TYPE----- Base64 编码的 DER 数据 （每行 64-76 字符） -----END TYPE----- 实际示例：X.509 证书 1 2 3 4 5 6 -----BEGIN CERTIFICATE----- MIIC/zCCAeegAwIBAgIUE7Few6gydfFoBDQ+1aAHba6absYwDQYJKoZIhvcNAQEL BQAwDzENMAsGA1UEAwwEVGVzdDAeFw0yNjA3MTYxNjA4MDFaFw0yNjA3MTcxNjA4 MDFaMA8xDTALBgNVBAMMBFRlc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK ... -----END CERTIFICATE----- 实际示例：私钥（PKCS#8 格式） 1 2 3 4 5 6 -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDwyIPC1HgFgg7v RcV/Lbxy/zb7j2hVcnZgOjg5sb6HbTLa18MfoFDhQzOfyYwTlrcE2MdUhST9VyDa 4Y+iWxY3XL6xZHaNNf7s0bWgxUwc2Z9sx2hCBaHP7zndwipcgE1n4BH82sRTtCbn ....

深入解析 TLS 1.3 记录层填充机制，了解如何通过填充隐藏真实数据长度，防止流量分析攻击，并介绍 OpenSSL 的配置方法。

TLS Keying Material Export（密钥材料导出）是 RFC 5705 定义的一个重要功能，允许从 TLS 会话中导出密钥材料，用于构建更上层的安全协议。本文介绍其原理及 OpenSSL 命令行实战。 什么是 Keying Material Export？ RFC 5705 定义了从 TLS 握手或连接中导出密钥材料的机制。导出的密钥材料可以用于： 额外密钥派生：为应用程序特定用途生成额外的加密密钥 Channel Binding：绑定 TLS 通道到上层协议（如 TLS-SRP） API 认证：某些 API 使用导出的密钥材料进行身份验证 导出公式如下： 1 2 3 4 5 6 exporter_label：导出标签（如 "client finished"） context_value：上下文值（可选） length：导出长度 ExporterMaterial(ExporterLabel, ContextValue, Length) = HKDF-Expand-Label(DerivedSecret, ExporterLabel, ContextValue, Length) 使用 OpenSSL s_client 导出 OpenSSL s_client 提供了 -keymatexport 和 -keymatexportlen 两个参数： 1 2 3 openssl s_client -connect example.com:443 \ -keymatexport "my-app-label" \ -keymatexportlen 32 参数说明 参数 说明 -keymatexport 导出使用的标签（label），字符串类型 -keymatexportlen 导出密钥材料的长度（字节），默认 20 完整示例 1 2 3 4 5 6 7 8 9 # 连接到测试服务器并导出 32 字节密钥材料 $ echo "Q" | openssl s_client -connect cloudflare....

FFDHE（Finite Field Diffie-Hellman Ephemeral）预定义组是 TLS 密钥交换的安全基础。相比自行生成的 DH 参数，使用 RFC 7919 标准的 FFDHE 组可以避免弱参数带来的安全风险。本文详细介绍 FFDHE 组的概念、优势及 OpenSSL 配置方法。 什么是 FFDHE 组？ FFDHE 组是一组经过严格审核的 Diffie-Hellman 参数，由 IETF 在 RFC 7919 中标准化。每个组都经过密码学安全验证，确保不存在数学后门或弱参数。 FFDHE 组列表 组名称 位数 安全等级 推荐场景 ffdhe2048 2048 112-bit 最低兼容要求 ffdhe3072 128-bit 128-bit 推荐生产环境 ffdhe4096 4096 192-bit 高安全需求 ffdhe6144 6144 192-bit+ 极高安全 ffdhe8192 8192 256-bit 特殊需求 为什么使用预定义组？ 安全性保证：参数经过密码学社区审核 互操作性：所有主流浏览器和服务器都支持 性能优化：使用安全素数，计算效率更高 避免弱参数：自行生成可能被植入后门 OpenSSL 配置方法 1. 通过 s_client 测试 FFDHE 密钥交换 1 2 3 4 5 # 测试服务器支持的 DH 组 echo | openssl s_client -connect example....

深入解析 X.509 证书策略（Certificate Policies）扩展，理解证书信任策略、OID 和证书类型之间的关系。

详解轻量级 ACME 客户端 acme.sh 的安装、证书申请、部署和自动续期配置，支持 Nginx、Apache、DNS 等多种验证方式。

本文介绍 TLS 1.3 中的 Encrypted Client Hello (ECH) 扩展，如何解决 SNI 明文泄露隐私问题。 SNI 隐私问题 在 TLS 握手过程中，客户端发送的 ClientHello 消息包含 Server Name Indication (SNI) 扩展，用于告知服务器希望连接的域名。问题在于：SNI 是明文传输的，任何中间设备（如 ISP、代理、防火墙）都可以看到用户正在访问哪个域名。 1 2 3 4 ClientHello ├── SNI: example.com ← 明文暴露！ ├── supported_versions: TLS 1.3 └── cipher_suites: [...] 这意味着即使流量本身被加密，网络观察者仍能知道你访问了哪些网站。 ECH 解决方案 Encrypted Client Hello (ECH) 是 RFC 8446 的扩展，旨在加密 SNI 及其他敏感的 ClientHello 扩展。ECH 在 ClientHello 外层使用 ECH公钥 加密敏感的内部 ClientHello，只有目标服务器能解密。 工作原理 DNS 配置：服务器在 DNS 的 HTTPS 记录中发布 ECH 公钥 客户端加密：客户端使用 ECH 公钥加密敏感的 ClientHello 信息 服务器解密：服务器用私钥解密，确认 ECH 隧道建立成功 握手继续：后续握手正常进行，SNI 已被加密 1 2 3 4 5 6 7 8 Outer ClientHello (明文) ├── SNI: ech....

在 TLS 握手过程中，客户端和服务器需要协商用于密钥交换的数学群组（Named Groups）。这个过程直接影响连接的安全性和兼容性。本文详细介绍 Named Groups 的概念、类型以及在 OpenSSL 和 Nginx 中的配置方法。 什么是 Named Groups？ Named Groups（命名组）是 TLS 协议中预先定义的一组数学参数，用于 (EC)DH 密钥交换。每个命名组对应一个具体的算法和参数组合，客户端和服务器通过名称协商使用哪个组进行密钥交换。 为什么 Named Groups 重要？ 安全性：不同的组提供不同的安全等级 兼容性：某些老旧系统只支持特定的组 性能：现代组（如 X25519）比传统组更高效 后量子安全：新的混合组支持量子抗性 组的类型 TLS 密钥交换组主要分为两类： 1. FFDHE（有限域 Diffie-Hellman） 基于传统离散对数难题，使用大整数模运算： 组名称 位数 安全等级 状态 ffdhe2048 2048 112-bit 推荐最低 ffdhe3072 3072 128-bit 推荐 ffdhe4096 4096 192-bit 高安全 ffdhe6144 6144 192-bit+ 极高安全 ffdhe8192 8192 256-bit 特殊需求 2. ECDHE（椭圆曲线 Diffie-Hellman） 基于椭圆曲线密码学，相同安全级别下密钥更短： 组名称 曲线 安全等级 x25519 Curve25519 128-bit x448 Curve448 256-bit secp256r1 NIST P-256 128-bit secp384r1 NIST P-384 192-bit secp521r1 NIST P-521 256-bit brainpoolP256r1 Brainpool 128-bit brainpoolP384r1 Brainpool 192-bit 3....

升级到 OpenSSL 3.x 后，很多老系统生成的证书无法验证通过，错误提示类似 error:0308010C:digital envelope routines。这通常是因为 OpenSSL 3.0 默认禁用了遗留算法（MD5、SHA-1、DES、RC4 等）。本文介绍如何配置 Legacy Provider 来处理这些遗留证书。 问题背景 OpenSSL 3.0 引入了 Provider 架构，密码学算法的实现被分离到独立的 Provider 中： Default Provider：提供现代安全算法（AES、SHA-2、ChaCha20 等） FIPS Provider：提供 FIPS 140-2 认证的算法 Legacy Provider：提供遗留算法（MD5、SHA-1、DES、RC4、CAST 等） 默认情况下，只有 Default Provider 启用，因此使用遗留算法的操作会失败。 验证问题现象 1. DES 加密失败 1 2 3 4 5 $ echo -n "test" | openssl enc -des-ede3-cbc enc: Unknown cipher: des-ede3-cbc error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported: ../crypto/evp/evp_fetch.c:386:Global default library context, Algorithm (des-ede3-cbc : 27), Properties (<null>) 2....