https://secdoc.jazor.net/tags/certificates/ Recent content in certificates on SecDoc Hugo -- gohugo.io zh-cn © 2026 黑豆子 Mon, 18 May 2026 00:07:06 +0800 https://secdoc.jazor.net/posts/x509-certificate-extensions-guide/ Mon, 18 May 2026 00:07:06 +0800 https://secdoc.jazor.net/posts/x509-certificate-extensions-guide/ X.509 证书的核心功能由扩展（Extensions）机制实现。扩展允许在证书中添加额外信息，定义证书的用途、约束、身份验证方式等关键属性。本文详细介绍常见扩展的作用和使用方法。 什么是证书扩展 X.509 v3 引入的扩展机制是现代 PKI 的基础。每个扩展由 OID（对象标识符）、关键性标志和扩展值组成。 扩展分为两类： 关键扩展（Critical）：证书使用者必须理解和处理的扩展，否则证书验证失败 非关键扩展（Non-critical）：可选的扩展，可被忽略但不应影响验证 常见扩展详解 1. Basic Constraints（基本约束） 定义证书是否为 CA（证书颁发机构）以及证书链深度。 1 2 3 4 5 6 7 8 # CA 证书 basicConstraints=CA:TRUE # 终端实体证书 basicConstraints=CA:FALSE # 无限制的 CA 路径长度 basicConstraints=CA:TRUE,pathlen:10 实际输出： 1 2 X509v3 Basic Constraints: CA:TRUE 2. Key Usage（密钥用法） 指定证书密钥的允许用途。 1 2 3 4 5 6 7 8 # 服务器认证证书 keyUsage=digitalSignature,keyEncipherment # CA 签名证书 keyUsage=digitalSignature,keyCertSign,cRLSign # 代码签名证书 keyUsage=digitalSignature,nonRepudiation 常见值： digitalSignature：数字签名 keyEncipherment：密钥加密 dataEncipherment：数据加密 keyCertSign：证书签名 cRLSign：CRL 签名 3. https://secdoc.jazor.net/posts/openssl-cross-signed-certificates/ Fri, 15 May 2026 00:09:25 +0800 https://secdoc.jazor.net/posts/openssl-cross-signed-certificates/ 交叉签名证书（Cross Signed Certificate）是 SSL/TLS 基础设施中一个重要但常被误解的概念。本文深入解释交叉签名的原理、适用场景以及 OpenSSL 操作方法。 什么是交叉签名？ 交叉签名是指由一个 CA（证书颁发机构）对另一个 CA 的证书进行签名。签名的对象是 CA 证书本身，而不是终端实体证书。 1 2 3 4 原始链：Root CA → Intermediate CA → Server Certificate 交叉签名链：Root CA (新) → Cross-signed Intermediate CA → Server Certificate ↑ 由新Root CA签名 关键特征： 交叉签名证书的 Subject（主题）与原始中间 CA 相同 Issuer（颁发者）变为进行交叉签名的根 CA 公钥与原始中间 CA 完全相同 典型使用场景 1. 多根 CA 信任 企业可能有两个不同的根 CA（如并购后的整合），需要让一张证书同时被两个根 CA 信任。 1 场景：公司有两个根 CA（Root CA 1 和 Root CA 2），都需要信任同一张服务器证书 2. 旧客户端兼容性 某些老旧客户端只信任特定的根 CA，通过交叉签名让新证书也能被这些客户端接受。 https://secdoc.jazor.net/posts/openssl-verify-certificate-chain-validation/ Thu, 14 May 2026 00:08:00 +0800 https://secdoc.jazor.net/posts/openssl-verify-certificate-chain-validation/ 详解 OpenSSL verify 命令的用法，包括证书链验证、CA 存储、partial_chain、trust 设置等核心参数，每个命令都经过实际验证。 https://secdoc.jazor.net/posts/dns-caa-record-guide/ Sat, 09 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/dns-caa-record-guide/ DNS CAA（Certification Authority Authorization）记录是一种 DNS 记录类型，用于声明哪些证书颁发机构（CA）可以为特定域名颁发 SSL/TLS 证书。作为域名所有者，通过配置 CAA 记录，可以有效防止未经授权的证书被颁发，保护网站安全。 什么是 CAA 记录 CAA 记录于 2013 年在 RFC 6844 中定义，允许域名管理者明确指定允许为该域名颁发证书的 CA。CAA 记录的工作原理是：当 CA 收到证书申请时，会查询域名的 DNS CAA 记录，如果发现没有授权给自己，则拒绝颁发证书。 CAA 记录的作用 防止证书被冒领：阻止未经授权的 CA 为你的域名颁发证书 提升安全等级：确保只有指定的 CA 可以提供证书服务 审计追踪：CAA 记录可以要求 CA 在颁发证书时发送通知 CAA 记录格式详解 CAA 记录的基本格式如下： 1 CAA <flags> <tag> <value> 关键字段 字段 说明 flags 8 位标志字段，目前使用 bit 0（关键位） tag 标签，指定 CAA 记录的类型的 value 标签对应的值 常用标签 CAA 记录支持多种标签，常用的包括： 标签 说明 示例 issue 授权指定 CA 颁发证书 issue "letsencrypt. https://secdoc.jazor.net/posts/certificate-pinning-guide/ Wed, 06 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/certificate-pinning-guide/ 证书固定（Certificate Pinning）是一种安全加固技术，通过将网站的身份与特定的证书或公钥绑定，防止攻击者使用伪造证书进行中间人攻击（MITM）。本文详细介绍证书固定的工作原理、实现方式和实战配置。 什么是证书固定 传统 HTTPS 验证依赖证书链信任机制：由浏览器内置的根证书库验证网站证书是否由可信 CA 签发。然而，如果攻击者能控制用户的根证书（如通过恶意软件或某些网络审查工具），就可以使用任意 CA 签发的伪造证书实施中间人攻击。 证书固定的核心思想是：不仅验证证书是否可信，还验证证书是否是我们预期的那一个。通过预先在客户端保存服务器的公钥指纹或证书指纹，客户端只会接受固定的那个证书，其他任何证书（包括合法 CA 签发的）都会被拒绝。 固定方式 1. 公钥指纹固定 直接固定服务器的公钥指纹，这是最推荐的方式。公钥是证书中最稳定的部分，即使证书续期，只要不更换密钥，指纹就保持不变。 1 2 3 4 5 6 # 提取证书公钥并计算 SHA-256 指纹 openssl s_client -connect example.com:443 2>/dev/null | \ openssl x509 -pubkey -noout | \ openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | \ base64 输出示例： 1 aqQ4L+Pac7Qy3Or7l6f9IypN8w1H64i48B4weiXJ2v4= 2. 证书指纹固定 直接固定整个证书的 SHA-256 指纹： 1 2 3 # 提取证书 SHA-256 指纹 openssl s_client -connect example. https://secdoc.jazor.net/posts/private-ca-internal-certificate-guide/ Sat, 02 May 2026 00:05:28 +0800 https://secdoc.jazor.net/posts/private-ca-internal-certificate-guide/ 在企业内网、测试环境或私有服务中，使用公共 CA 签发的证书不仅成本高昂，还可能带来安全风险。搭建私有 CA（Certificate Authority）可以完全掌控证书生命周期，实现内部服务的 HTTPS 加密和双向认证（mTLS）。本文将详细介绍如何使用 OpenSSL 搭建私有 CA 并签发内部证书。 什么是私有 CA 私有 CA 是组织内部自行搭建和维护的证书颁发机构，与 Let’s Encrypt、DigiCert 等公共 CA 类似，但不向外部公开。私有 CA 通常用于： 内网 HTTPS：内部系统之间的安全通信 开发测试：模拟生产环境的 HTTPS 流程 mTLS 双向认证：验证客户端和服务端双方身份 物联网设备：无法访问公共 CA 的嵌入式设备 搭建私有 CA 架构 典型的私有 CA 采用两级结构： 根 CA（Root CA）：信任的起点，长期有效（10-20 年），离线存储 颁发 CA（Issuing CA）：实际签发终端证书，有效期较短（1-3 年） 这种设计更安全：根 CA 离线保存，日常签发由颁发 CA 完成，泄露风险更低。 创建根 CA 根 CA 是整个 PKI 体系的信任根基，需要妥善保管。 1. 生成根 CA 私钥 1 openssl genrsa -out root-ca.key 4096 生成 4096 位 RSA 私钥。私钥必须严格保密，建议设置文件权限为 600。 https://secdoc.jazor.net/posts/openssl-verify-command-usage/ Thu, 30 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-verify-command-usage/ openssl verify 是 OpenSSL 中最常用的证书验证工具，用于验证证书链的完整性和有效性。本文详细介绍其常用选项和实战场景。 基本语法 1 openssl verify [options] certificate.pem 常用选项 指定可信 CA 选项 说明 -CAfile <file> 指定一个包含可信 CA 证书的文件 -CApath <dir> 指定可信 CA 证书目录（需要哈希索引） -CAstore <uri> 从 URI 加载可信证书 1 2 3 4 5 # 使用 CAfile 验证 openssl verify -CAfile ca.crt server.crt # 同时使用 CAfile 和 CApath openssl verify -CAfile ca.crt -CApath /etc/ssl/certs server.crt 指定中间证书 1 2 # -untrusted 指定中间证书（证书链中的非可信证书） openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt 常用验证选项 选项 说明 -partial_chain 接受部分链验证（只要链到某个可信 CA 即可） -show_chain 显示完整的证书链信息 -purpose <purpose> 验证证书用途（sslserver, sslclient, etc. https://secdoc.jazor.net/posts/ssh-certificate-authentication-guide/ Wed, 29 Apr 2026 00:05:37 +0800 https://secdoc.jazor.net/posts/ssh-certificate-authentication-guide/ SSH 证书认证是一种比传统公钥认证更安全的方案。本文介绍 SSH 证书的工作原理和配置方法。 传统公钥认证的问题 传统的 SSH 公钥认证需要在每台服务器上添加用户的公钥： 1 2 # 用户将公钥发送到服务器 ssh-copy-id user@server 这种方式在大规模环境中存在以下问题： 密钥管理困难：新增或撤销用户需要手动更新所有服务器 无时效性：公钥永久有效，离职后难以撤销 无法追踪：无法知道谁在什么时候登录过 扩展性差：成百上千台服务器时维护成本极高 SSH 证书认证的原理 SSH 证书认证引入**证书颁发机构（CA）**的概念： CA 密钥：管理员创建一个 CA 私钥，用于签发证书 用户证书：CA 使用私钥对用户公钥进行签名，生成证书 服务器信任 CA：服务器只需配置信任 CA 公钥，无需逐个添加用户公钥 证书验证：用户登录时提交证书，服务器通过 CA 公钥验证证书有效性 证书包含的信息 用户公钥 用户 ID（Key ID） 有效期（起始时间 + 结束时间） 允许的登录用户名（Principals） CA 签名 创建 SSH CA 首先创建 CA 密钥对。建议使用 ED25519 算法： 1 2 3 4 5 # 创建用户证书CA ssh-keygen -t ed25519 -f ~/.ssh/user_ca -C "SSH User CA" # 创建主机证书CA（可选，用于验证服务器身份） ssh-keygen -t ed25519 -f ~/. https://secdoc.jazor.net/posts/post-quantum-cryptography-nist-standard/ Wed, 29 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/post-quantum-cryptography-nist-standard/ 量子计算的快速发展对现代密码学构成了前所未有的威胁。当前广泛使用的 RSA、ECDSA 等公钥密码算法依赖于大整数分解或离散对数问题的计算难度，但量子计算机的 Shor 算法可以在多项式时间内解决这些问题。这意味着当大规模量子计算机成熟时，现有的 SSL/TLS 证书、SSH 密钥、数字签名都将面临被破解的风险。 什么是后量子密码学 后量子密码学（Post-Quantum Cryptography，PQC）是指能够在经典计算机上运行，但能够抵御量子计算机攻击的密码学算法。这些算法不依赖量子力学原理，而是基于量子计算机也难以高效求解的数学问题，如格密码（Lattice-Based）、编码密码（Code-Based）、多变量密码（Multivariate）等。 与量子密钥分发（QKD）不同，PQC 是软件层面的解决方案，可以在现有硬件和网络上部署，无需专门的量子通信设备。 NIST PQC 标准化进程 美国国家标准与技术研究院（NIST）自 2016 年启动后量子密码学标准化项目，经过多轮筛选，于 2024 年 8 月发布了首批三个最终标准。 首批发布的三个标准 标准名称 类型 底层技术 用途 ML-KEM 密钥封装机制 模块格（Module-Lattice） 密钥交换、TLS 握手 ML-DSA 数字签名 模块格（Module-Lattice） 证书签名、代码签名 SLH-DSA 数字签名 哈希（Hash-Based） 替代签名方案 ML-KEM（原 Kyber）是基于格理论的密钥封装机制，将取代传统的 Diffie-Hellman 密钥交换，用于 TLS 1.3 握手阶段的密钥协商。 ML-DSA（原 Dilithium）是基于格理论的数字签名算法，将作为主要的签名方案，用于 SSL/TLS 证书、代码签名等场景。 SLH-DSA（原 SPHINCS+）是基于哈希的签名算法，作为备份方案，安全性基于哈希函数的抗碰撞性。 正在标准化的候选算法 除了首批三个标准，NIST 还在评估以下算法： Falcon：基于格的高效签名算法，签名更短，适用于带宽受限场景 HQC：基于编码的密钥封装机制，提供额外的安全保障 实际影响与迁移时间线 对 TLS/SSL 的影响 当前的 TLS 协议使用 RSA 或 ECDSA 进行身份验证，使用 ECDHE 进行密钥交换。迁移到 PQC 后： https://secdoc.jazor.net/posts/certificate-transparency-%E5%8E%9F%E7%90%86%E4%B8%8E%E9%AA%8C%E8%AF%81/ Tue, 28 Apr 2026 00:06:06 +0800 https://secdoc.jazor.net/posts/certificate-transparency-%E5%8E%9F%E7%90%86%E4%B8%8E%E9%AA%8C%E8%AF%81/ 什么是证书透明度 证书透明度（Certificate Transparency，简称 CT）是 Google 提出的一个开源框架，旨在为 TLS 证书提供公开的审计和监控机制。它的核心目标是检测恶意或错误签发的证书，防止证书颁发机构（CA）未经授权签发证书。 在 CT 出现之前，如果某个 CA 被攻击或故意签发虚假证书，这些证书可能在很长时间内不被发现。CT 通过要求所有证书必须记录在公开的日志服务器上，使得任何人都可以审计证书签发行为。 CT 架构解析 证书透明度由三个核心组件构成： 1. 日志服务器（Log Server） 日志服务器是 CT 的核心，是一个仅追加（append-only）的 Merkle 树结构数据库。每个日志服务器接收并存储证书条目，主要特性： 仅追加：一旦记录被添加，就不能删除或修改 Merkle 树：使用密码学哈希树结构，可以高效验证数据完整性 公开可访问：任何人都可以提交证书或查询日志 主流的公开日志服务器包括： Google Argon（ct.googleapis.com/pki/argon) DigiCert Log（ct.digicert.com/log) Let’s Encrypt（ct.letsencrypt.org) 2. 监控器（Monitor） 监控器定期检查日志服务器，查找可疑的证书签发行为。例如： 为知名域名签发的异常证书 仿冒知名网站的证书 来自不可信 CA 的证书 常见的监控服务包括： crt.sh - 免费证书搜索数据库 Google Monitor Cloudflare Monitor 3. 审计员（Auditor） 审计员验证日志服务器的行为，确保它们： 正确记录了所有提交的证书 没有作弊或隐瞒记录 响应一致的查询 浏览器通常内置审计员功能，在验证证书时自动检查 SCT。 SCT：签名证书时间戳 当证书被提交到 CT 日志时，日志服务器会返回 Signed Certificate Timestamp（SCT）。SCT 包含： 日志服务器 ID：签发 SCT 的日志服务器标识 序列号：该证书在日志中的唯一编号 时间戳：证书被记录的时间 签名：日志服务器对上述信息的数字签名 浏览器在验证 TLS 连接时，会检查证书是否附带有效的 SCT。根据浏览器策略，通常要求至少 1-2 个 SCT 才能完全信任证书。 https://secdoc.jazor.net/posts/ocsp-stapling-deep-dive/ Tue, 21 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/ocsp-stapling-deep-dive/ 什么是 OCSP Stapling OCSP Stapling（正式名称为 TLS Certificate Status Request）是一种 TLS 扩展机制，允许服务端在 TLS 握手过程中主动向客户端提供证书的状态信息，而无需客户端自行向 CA 的 OCSP 响应服务器发起查询。 它的核心价值在于：将证书状态验证的责任从客户端转移到服务端，同时保护用户隐私、提升连接速度。 为什么需要 OCSP Stapling 要理解 OCSP Stapling 的价值，先看没有它时证书撤销检查的三种方式。 方式一：CRL（证书吊销列表） CA 定期发布一个包含所有已吊销证书序列号的列表（CRL），客户端下载后自行检查。 1 2 # 查看 CRL 分布点（CRL Distribution Points） openssl x509 -in cert.pem -noout -text | grep -A2 "CRL Distribution" 问题很明显：CRL 文件会随着时间不断增长，下载和解析开销越来越大。即使使用增量 CRL（Delta CRL），也难以应对大规模部署。 方式二：OCSP（在线证书状态协议） 客户端直接向 CA 的 OCSP 响应服务器发送查询，获取单张证书的实时状态。 1 2 3 # 提取证书的 OCSP 响应器 URL openssl x509 -in cert.pem -noout -ocsp_uri # 示例输出: http://ocsp. https://secdoc.jazor.net/posts/ocsp-certificate-status-check/ Thu, 16 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ocsp-certificate-status-check/ OCSP（Online Certificate Status Protocol）是用于实时检查证书是否被吊销的协议。相比 CRL，OCSP 无需下载完整吊销列表，查询效率更高。本文介绍 OCSP 原理及 OpenSSL 命令行操作。 什么是 OCSP？ 当浏览器验证 TLS 证书时，除了检查证书链和有效期，还需确认证书未被吊销。传统方式是下载 CRL（Certificate Revocation List），但列表会随时间增长。OCSP 允许客户端直接查询证书颁发机构，获取特定证书的实时状态。 OCSP 响应类型 状态 含义 good 证书有效，未被吊销 revoked 证书已被吊销 unknown 响应者不知道该证书 从证书提取 OCSP 信息 获取证书的 OCSP 响应者地址 1 openssl x509 -in certificate.crt -noout -ocsp_uri 输出示例： 1 http://ocsp.digicert.com 获取颁发者信息 OCSP 查询需要知道证书的颁发者（CA）： 1 2 3 4 5 # 获取证书颁发者 openssl x509 -in certificate.crt -noout -issuer # 获取颁发者证书 openssl x509 -in certificate.crt -noout -issuer_hash 实际 OCSP 查询示例 使用 OpenSSL 进行 OCSP 查询 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 获取目标证书和颁发者证书 openssl s_client -connect google. https://secdoc.jazor.net/posts/mtls-mutual-tls-authentication/ Sat, 11 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/mtls-mutual-tls-authentication/ 什么是双向 TLS 认证 普通 HTTPS 连接中，客户端验证服务器证书，确保连接的是真实的服务器。双向 TLS（Mutual TLS，简称 mTLS） 在此基础上增加了服务器对客户端的验证——客户端必须提供有效的证书才能建立连接。 这种认证方式比用户名密码更安全，广泛用于： API 服务间的身份认证 零信任网络架构 企业内部系统访问控制 高安全要求的金融、医疗系统 工作原理 mTLS 握手过程： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 客户端 服务器 | | |---------- ClientHello --------------->| |<--------- ServerHello ----------------| |<--------- Certificate ----------------| (服务器证书) |<--------- CertificateRequest ---------| (请求客户端证书) |<--------- ServerHelloDone ------------| | | |---------- Certificate ---------------->| (客户端证书) |---------- ClientKeyExchange --------->| |---------- CertificateVerify --------->| (证明拥有私钥) |---------- Finished ------------------>| |<--------- Finished -------------------| | | |====== 加密通信通道 ====================| 关键区别：服务器发送 CertificateRequest，客户端响应自己的证书并用私钥签名证明身份。 https://secdoc.jazor.net/posts/openssl-check-certificate-validity/ Sun, 05 Apr 2026 17:20:00 +0800 https://secdoc.jazor.net/posts/openssl-check-certificate-validity/ 证书过期会导致服务不可用，提前监控证书有效期是运维的基本功。OpenSSL 提供了多种检查证书有效期的方法。 检查远程服务器证书 查看有效期 1 echo | openssl s_client -connect www.baidu.com:443 -servername www.baidu.com 2>/dev/null | openssl x509 -noout -dates 输出： 1 2 notBefore=Jul 9 07:01:02 2025 GMT notAfter=Aug 10 07:01:01 2026 GMT notBefore：证书生效日期 notAfter：证书过期日期 检查本地证书文件 1 openssl x509 -in certificate.crt -noout -dates 查看剩余天数 1 openssl x509 -in certificate.crt -noout -checkend 0 输出： Certificate will not expire：证书未过期 Certificate will expire：证书已过期 检查是否在 30 天内过期（2592000 秒）： 1 openssl x509 -in certificate.crt -noout -checkend 2592000 返回码： https://secdoc.jazor.net/posts/openssl-certificate-format-conversion/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-certificate-format-conversion/ 详解 OpenSSL 在 PEM、DER、P7B、PFX 等证书格式之间的转换命令，每个命令都经过实际验证。 https://secdoc.jazor.net/posts/openssl-certificate-chain-validation/ Tue, 31 Mar 2026 00:00:56 +0800 https://secdoc.jazor.net/posts/openssl-certificate-chain-validation/ OpenSSL 证书链验证详解 证书链验证是 SSL/TLS 安全的核心机制。本文将详细介绍如何使用 OpenSSL 工具进行证书链验证，确保连接的安全性。 什么是证书链？ 证书链（Certificate Chain）是一系列证书的有序集合，用于验证终端实体证书的有效性。典型的证书链包含： 终端实体证书：最终服务的证书 中间证书：由 CA 签发的证书 根证书：受信任的根 CA 证书 OpenSSL 验证命令 基本验证 1 2 3 # 验证证书和私钥匹配 openssl x509 -noout -modulus -in server.crt | openssl md5 openssl rsa -noout -modulus -in server.key | openssl md5 证书链验证 1 2 # 验证证书链 openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt 实战案例：完整证书链验证 场景描述 验证包含终端证书、中间证书和根证书的完整证书链。 1. 准备证书文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 创建测试目录 mkdir -p /tmp/cert-test cd /tmp/cert-test # 生成根证书 openssl genrsa -out root. https://secdoc.jazor.net/posts/certificates-crl-validation-guide/ Sun, 29 Mar 2026 00:00:16 +0800 https://secdoc.jazor.net/posts/certificates-crl-validation-guide/ 证书吊销列表验证指南 证书吊销列表（Certificate Revocation List, CRL）是 PKI 系统中用于撤销已颁发证书的重要机制。本文将详细介绍如何使用 OpenSSL 工具验证证书的吊销状态。 什么是证书吊销列表 CRL 是由证书颁发机构（CA）维护的已撤销证书的列表。当证书出现以下情况时，会被添加到 CRL 中： 私钥泄露 证书信息变更 用户不再需要该证书 CA 发现证书存在问题 验证证书吊销状态的命令 1. 查看证书基本信息 1 openssl x509 -in certificate.pem -text -noout 2. 下载 CRL 文件 1 2 3 4 5 # 从证书中提取 CRL 分布点 openssl x509 -in certificate.pem -text -noout | grep -A 5 "CRL Distribution Points" # 下载 CRL 文件 wget -O crl.crl http://crl.example.com/crl.crl 3. 验证证书是否被吊销 1 openssl x509 -in certificate.pem -noout -purpose sslserver -verifycrl crl. https://secdoc.jazor.net/posts/openssl-certificate-management/ Sat, 28 Mar 2026 00:00:34 +0800 https://secdoc.jazor.net/posts/openssl-certificate-management/ OpenSSL 是最强大的证书管理工具之一。本文聚焦日常证书管理中最常用的操作：生成、签名、转换和验证。 生成私钥 生成 RSA 私钥 1 2 3 4 5 6 7 8 # 生成 2048 位 RSA 私钥 openssl genrsa -out private.key 2048 # 生成 4096 位 RSA 私钥（更安全） openssl genrsa -out private.key 4096 # 生成带密码保护的私钥 openssl genrsa -aes256 -out private-encrypted.key 2048 生成 EC 私钥 1 2 3 4 5 # 生成 EC 私钥（P-256 曲线） openssl ecparam -name prime256v1 -genkey -noout -out ec-private.key # 生成 EC 私钥（P-384 曲线） openssl ecparam -name secp384r1 -genkey -noout -out ec-private-384. https://secdoc.jazor.net/posts/openssl-x509-command-guide/ Fri, 27 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-x509-command-guide/ openssl x509 是日常运维中最常用的证书查看工具。本文聚焦于查看和解析证书信息，不涉及证书生成。 基本语法 1 openssl x509 [options] -in <certificate file> 常用查看命令 查看证书完整信息 1 openssl x509 -in cert.pem -text -noout 输出包含：版本、序列号、签名算法、颁发者、有效期、主体、公钥、扩展信息。 只查看关键字段 1 2 3 4 5 6 7 8 9 10 11 # 查看主体（Subject） openssl x509 -in cert.pem -subject -noout # 查看颁发者（Issuer） openssl x509 -in cert.pem -issuer -noout # 查看有效期 openssl x509 -in cert.pem -dates -noout # 查看序列号 openssl x509 -in cert.pem -serial -noout 查看公钥信息 1 openssl x509 -in cert. https://secdoc.jazor.net/posts/csr-certificate-signing-request/ Tue, 24 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/csr-certificate-signing-request/ 什么是 CSR？ CSR（Certificate Signing Request，证书签名请求） 是申请 SSL/TLS 证书时向证书颁发机构（CA）提交的文件。它包含了申请者的公钥和身份信息，由申请者的私钥签名。 CSR 的用途 申请 SSL/TLS 证书 - 向 CA 提交 CSR 申请服务器证书 身份验证 - CSR 中的信息用于验证申请者身份 密钥关联 - 将公钥与域名/组织信息绑定 CSR 包含哪些信息？ 一个标准的 CSR 包含以下信息： 字段 说明 示例 C (Country) 国家代码 CN ST (State) 州/省 Beijing L (Locality) 城市 Beijing O (Organization) 组织名称 Example Corp OU (Organization Unit) 部门 IT Department CN (Common Name) 通用名称/域名 example.com emailAddress 电子邮件 admin@example.com 此外，CSR 还包含： 公钥 - 与私钥配对的公钥 签名 - 使用私钥生成的数字签名 可选扩展 - 如 Subject Alternative Name (SAN) 使用 OpenSSL 生成 CSR 基本命令格式 1 2 3 4 5 # 生成私钥的同时生成 CSR（交互式） openssl req -new -newkey rsa:2048 -nodes -keyout domain. https://secdoc.jazor.net/posts/ssl-tls-certificates-deep-dive/ Tue, 24 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssl-tls-certificates-deep-dive/ SSL/TLS 证书是互联网信任体系的基石。本文深入剖析证书的工作原理、类型选择、配置最佳实践，以及常见问题的排查方法。 一、证书工作原理 TLS 握手过程 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 客户端 服务器 | | | 1. ClientHello | | (支持的加密套件、TLS版本、随机数) | | --------------------------------------> | | | | 2. ServerHello | | (选定加密套件、TLS版本、随机数) | | + Certificate (服务器证书链) | | + ServerKeyExchange (可选) | | + CertificateRequest (可选,双向认证) | | <-------------------------------------- | | | | 3.