tls

OpenSSL 3.0 引入的 Provider 架构是其最重要的架构变革之一。它将密码学算法的实现与 OpenSSL 核心解耦，使得算法可以独立加载、更新和替换。本文深入解析 Provider 的工作机制。 为什么需要 Provider？ 在 OpenSSL 1.1.x 及之前版本中，所有密码学算法（对称加密、非对称加密、哈希、签名等）都内置在 OpenSSL 库中。这种架构存在以下问题： 紧耦合：算法实现与核心库绑定，无法独立更新 扩展困难：添加新算法需要修改 OpenSSL 源码 Legacy 负担：过时的算法实现（如 MD5、DES）始终存在 OpenSSL 3.0 引入的 Provider 架构完美解决了这些问题。 Provider 架构概述 核心概念 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ┌─────────────────────────────────────────────────────┐ │ Application │ └──────────────────────┬──────────────────────────────┘ │ OSSL_DECODER / OSSL_ENCODER ┌──────────────────────▼──────────────────────────────┐ │ OpenSSL 3.0 Core │ │ ┌──────────────────────────────────────────────┐ │ │ │ Algorithm Fetch Layer │ │ │ │ (根据 Property Query 选择合适的 Provider) │ │ │ └──────────────────────────────────────────────┘ │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌─────────────┐ ┌─────────────┐ │ Default Prov │ │ Legacy Prov │ │ FIPS Prov │ │ (默认算法集) │ │ (遗留算法) │ │ (合规算法) │ └───────────────┘ └─────────────┘ └─────────────┘ Provider 类型 OpenSSL 3....

在管理 SSL/TLS 证书和私钥时，你可能会遇到两种不同的私钥格式：PKCS#1 和 PKCS#8。本文详细介绍这两种格式的区别、使用场景以及转换方法。 什么是 PKCS#1 PKCS#1 是 RSA 加密标准的第一个版本，定义了 RSA 密钥的数学结构。其 PEM 格式的私钥文件头部为： 1 -----BEGIN RSA PRIVATE KEY----- PKCS#1 只支持 RSA 密钥，格式相对简单，直接存储 RSA 算法的参数（n, e, d, p, q 等）。 什么是 PKCS#8 PKCS#8 是通用的私钥格式标准，支持多种算法（RSA、EC、Ed25519 等）。其 PEM 格式的私钥文件头部为： 1 -----BEGIN PRIVATE KEY----- PKCS#8 使用更通用的结构，可以封装任意类型的私钥，并且支持加密存储。 格式对比 特性 PKCS#1 PKCS#8 PEM 头部 -----BEGIN RSA PRIVATE KEY----- -----BEGIN PRIVATE KEY----- 支持算法 仅 RSA RSA、EC、Ed25519 等多种算法 兼容性 旧版系统和应用 现代系统和应用（OpenSSL 1.0+） 生成与转换命令 生成 PKCS#8 格式私钥（默认） 1 2 3 4 5 6 7 8 # 生成 RSA 私钥（PKCS#8 格式，默认） openssl genrsa -out key....

DANE（DNS-Based Authentication of Named Entities）是一种基于 DNS 的证书认证机制，通过 TLSA 记录将证书信息绑定到域名上。本文详细介绍 DANE 的原理、TLSA 记录格式以及在 Nginx 中的配置方法。 传统证书验证的问题 传统的 TLS 证书验证依赖 CA（证书颁发机构）体系，存在以下问题： CA 可能被攻陷：全球有数百个可信 CA，一个 CA 被攻陷即可签发任意域名证书 证书透明度不足：难以发现恶意或错误签发的证书 依赖链复杂：多级中间 CA 增加验证复杂度和风险 什么是 DANE？ DANE 定义于 RFC 6698，是一种基于 DNS 的证书认证机制。它通过在 DNS 中添加 TLSA 记录（TLS Authentication），将证书信息直接与域名绑定，绕过传统 CA 验证体系。 DANE 的核心优势 防范 CA 被攻陷：即使 CA 被攻陷，攻击者也无法伪造 DNS 中的 TLSA 记录 自建 CA 的福音：企业内部 CA 签发的证书也能被客户端信任 证书固定：将证书指纹写入 DNS，客户端只能接受指定证书 TLSA 记录格式 TLSA 记录包含四个字段，格式为：Usage Selector MatchingType AssociationData 1 _443._tcp.example.com. IN TLSA 3 1 1 73D2522B56547E710E480F27CCFD6F75959422668C2C300B98AC07E6D7 1....

X.509 证书中的 Name Constraints（名称约束）扩展是 PKI 安全的核心机制之一。它允许 CA 证书限制其下级证书的适用范围，防止被滥用来签发任意域名的证书。本文详细介绍其工作原理和实际使用方法。 什么是 Name Constraints Name Constraints 是 X.509 证书标准（RFC 5280）定义的一个关键扩展，主要用于 CA 证书。它声明了该 CA 可以签发证书的域名和 IP 地址范围。 作用场景 限制中间 CA 权限：企业私有 CA 可以限制下级 CA 只能签发特定域名的证书 分层授权：在大型组织中实现细粒度的证书管理权限划分 安全边界：防止某个被入侵的子 CA 被用来签发其他域名的证书 约束类型 Name Constraints 包含两种类型的约束： 类型 说明 permitted 允许使用的名称范围 excluded 禁止使用的名称范围 这两个可以同时使用，excluded 优先级更高。 证书格式 Name Constraints 扩展的 ASN.1 结构如下： 1 2 3 4 5 6 7 8 9 10 11 12 NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1....

深入解析 SSL 证书链的正确顺序，常见错误原因，以及使用 OpenSSL 和 Nginx 正确配置证书链的实战指南。

在需要对加密操作进行合规性控制的场景中，FIPS 140-2（或 FIPS 140-3）是一个重要的标准。本文介绍如何在 OpenSSL 中启用和配置 FIPS 模式。 什么是 FIPS 140-2？ FIPS 140-2 是美国国家标准与技术研究院（NIST）发布的密码学模块安全要求标准。它定义了四个安全等级（Level 1-4），要求密码学实现经过严格测试和验证。 关键点： 强制要求在政府机构和受监管行业使用 OpenSSL 通过 FIPS 模块（OpenSSL-FIPS）提供支持 FIPS 模式开启后，仅允许使用经认证的加密算法 环境检查 首先检查当前 OpenSSL 版本： 1 openssl version -a 注意输出中的 FIPS 标记。如果显示 fips-mode 相关信息，说明已支持 FIPS。 安装 OpenSSL FIPS 模块 方法一：使用系统包管理器（推荐） Ubuntu/Debian： 1 2 sudo apt update sudo apt install openssl-fips RHEL/CentOS： 1 sudo yum install openssl-fips 方法二：从源码编译 1 2 3 4 5 6 7 8 9 # 下载 OpenSSL FIPS 模块源码（以 2....

TLS 1.3 是目前最安全的传输层协议版本，相比 TLS 1.2 有显著的性能和安全优势。本文介绍如何在 Nginx 中正确配置 TLS 1.3，并提供经过验证的配置示例。 TLS 1.3 的核心优势 TLS 1.3 相比 TLS 1.2 有以下关键改进： 握手简化：从 2-RTT 降至 1-RTT（0-RTT 可选），连接建立更快 移除不安全算法：仅保留 AEAD 加密套件，禁用 CBC 模式和 RC4 前向安全性：强制使用 ECDHE 密钥交换，始终支持 PFS 抗重放攻击：0-RTT 模式有重放保护机制 基础配置 以下是 Nginx TLS 1.3 的基础配置： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 server { listen 443 ssl http2; server_name example....

ChaCha20-Poly1305 是 TLS 1.2 和 TLS 1.3 中广泛使用的 AEAD（带认证的加密）密码套件，尤其在移动设备上因性能优势被广泛采用。本文深入解析其加密原理及 OpenSSL 命令行实现。 1. 什么是 AEAD？ AEAD（Authenticated Encryption with Associated Data）同时提供： 机密性：通过加密保护数据隐私 完整性：通过 MAC（消息认证码）验证数据未被篡改 关联数据：可选择性地对未加密的元数据进行认证 常见的 AEAD 组合包括 AES-GCM、ChaCha20-Poly1305、ChaCha20-Poly1305-IETF。 2. ChaCha20 加密算法 2.1 算法概述 ChaCha20 是 Daniel J. Bernstein 于 2008 年设计的流密码算法，作为 Salsa20 的改进版本。其核心特点： 特性 说明 类型 对称流密码 密钥长度 256 位 Nonce 长度 96 位（12 字节） 块大小 512 位（64 字节） 迭代次数 20 轮（故名 ChaCha20） 2.2 加密原理 ChaCha20 使用**置换置换网络（PRP）**结构，将密钥、Nonce 和计数器混合生成 512 位的密钥流块： 1 2 ChaCha20(key, nonce, counter) → keystream blocks ciphertext = plaintext ⊕ keystream 核心操作包括：...

在 OpenSSL 编程中，SSL_get_error() 是排查 SSL/TLS 连接问题的核心函数。当 SSL_read() 或 SSL_write() 返回负数时，需要调用它来确定具体的错误类型。本文详细介绍各错误码的含义及处理方法。 函数原型 1 2 3 #include <openssl/ssl.h> int SSL_get_error(const SSL *ssl, int ret); ret 是上次 SSL 操作的返回值（通常为负数），函数返回以下错误码之一： 错误码 常量 含义 0 SSL_ERROR_NONE 操作成功完成 1 SSL_ERROR_SSL 协议层面的内部错误 2 SSL_ERROR_WANT_READ 操作未完成，需要更多数据 3 SSL_ERROR_WANT_WRITE 操作未完成，需要写入更多数据 4 SSL_ERROR_WANT_X509_LOOKUP 等待 X509 回调完成 5 SSL_ERROR_SYSCALL 系统调用错误，检查 errno 6 SSL_ERROR_ZERO_RETURN 对端关闭连接 7 SSL_ERROR_WANT_CONNECT 等待连接完成 8 SSL_ERROR_WANT_ACCEPT 等待 Accept 完成 9 SSL_ERROR_WANT_ASYNC 等待异步操作 10 SSL_ERROR_WANT_ASYNC_JOB 等待异步任务 11 SSL_ERROR_WANT_CLIENT_HELLO_CB 等待 ClientHello 回调 12 SSL_ERROR_WANT_RETRY_VERIFY 等待重试验证 常见错误码详解 SSL_ERROR_SSL (1) 这是最常见的错误，表示协议层面的内部错误。通常由以下原因导致：...

深入解析 TLS 1.3 握手摘要（Transcript）机制，以及 CertificateVerify 消息如何验证证书私钥所有权。