openssl

证书指纹（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 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....

在开发涉及加密通信或数据保护的应用时，直接调用底层密码学算法（如 AES、RSA、SHA）既繁琐又容易出错。OpenSSL 提供了 EVP（EnVElope Password）编程接口，将底层算法封装为统一的 API，开发者无需关心算法细节，只需调用统一的函数即可完成加密、哈希、签名等操作。 为什么使用 EVP 接口 直接使用 OpenSSL 的底层 API（如 AES_* 系列函数）存在以下问题： 算法切换困难：代码与特定算法强耦合，换算法需要大幅修改 安全风险：开发者可能忽略填充模式、IV 初始化等关键细节 接口不一致：不同算法的 API 风格各异，学习成本高 EVP 接口解决了这些问题： 统一 API：所有算法使用相同的使用模式 自动填充：AEAD 模式自动处理填充 易于切换：一行代码即可切换算法 内存安全：自动管理临时缓冲区 EVP 加密解密 EVP_CIPHER 相关的 API 用于对称加密和解密。以下是一个完整的示例，演示如何使用 EVP 接口进行 AES-256-GCM 加密： 加密示例 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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 #include <openssl/evp....

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

在 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....

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....