文章总结： RFC9925定义了未签名X.509证书的配置文件，使用占位符签名算法id-alg-unsigned替代自签名，以解决后量子签名过大和密钥重用问题。它更新了RFC5280，允许在仅需主题信息时省略签名，但要求验证器必须拒绝该算法用于证书路径。文档提供了构建方法、颁发者字段处理建议及安全考虑，强调应用程序应将其视为无法识别的签名算法。 综合评分： 86 文章分类： 技术标准
未签名的X.509证书
衡水石头哥 衡水石头哥
铁军哥
2026年7月12日 07:37 北京
在小说阅读器读本章
去阅读
RFC9925：Unsigned X.509 Certificates，February 2026
梗概
本文档定义了占位符X.509签名算法，该算法可用于证书使用者不希望验证签名的情况。作为其中的一部分，它更新了RFC 5280。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc9925。
版权声明
版权所有（c）2026 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括《信托法律条款》第4.e节中所述的修订版BSD许可证文本，并且不提供修订版BSD许可证中所述的保证。
1、简介
X.509证书 [RFC5280] 与PKI中的两个实体相关：有关主体的信息和来自颁发者的证明。将PKI视为以实体为节点的图，如 [RFC4158] 中所示，证书是主体和颁发者之间的边。
在某些情况下，应用程序需要独立的主题信息而不是证书。在图论模型中，应用程序需要一个节点，而不是边。例如，证书路径验证（[RFC5280]的第6节）从信任锚开始，有时称为根证书颁发机构（根CA）。应用程序在带外信任此信任锚信息，并且不需要发行者的签名。
X.509没有定义这种情况的结构。相反，X.509信任锚通常用“自签名”证书表示，其中主体的密钥对其自身进行签名。其他格式（例如 [RFC5914]）的存在是为了传达信任锚，但自签名证书仍然被广泛使用。
此外，某些TLS [RFC8446] 服务器部署在不打算提供CA颁发的身份时使用自签名终端实体证书，而是期望依赖方通过带外（例如，通过已知指纹）对证书进行身份验证。
这些自签名通常没有安全价值，接收方不会检查，并且仅用作占位符以满足X.509证书的语法要求。
将签名计算为占位符有一些缺点：
* 后量子签名算法很大，因此包含自签名会显着增加有效负载的大小。
* 如果主体是最终实体而不是CA，则计算X.509签名可能会因密钥的预期用途而遭受跨协议攻击。
* 这种自签名是否需要基本约束中的CA位或密钥使用中的keyCertSign是不明确的。如果密钥用于非X.509用途，则断言这些功能会带来不必要的风险。
* 如果主体是最终实体，并且最终实体的密钥不是签名密钥（例如密钥封装机制（KEM）密钥），则没有可与该密钥一起使用的有效签名算法。
本文档定义了未签名X.509证书的配置文件，当证书用作主题信息的容器而没有任何特定颁发者时，可以使用该配置文件。
2、需求语言
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。
3、构建未签名证书
本节描述发送方如何构造未签名的证书。
3.1、签名
要构建未签名的X.509证书，发送方必须将证书的签名算法和TBSCertificate的签名字段分别设置为具有算法id-alg-unsigned的AlgorithmIdentifier，定义如下：
id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36}
id-alg-unsigned的参数必须被省略。证书的签名值字段必须是长度为零的位串。
3.2、颁发者
在应用程序仅需要主题信息的情况下，未签名证书会取代自签名证书。它没有发行者，因此 [RFC5280] 中定义的配置文件中的某些要求无法有意义地应用。但是，应用程序可能具有从 [X.509] 和 [RFC5280] 派生的预先存在的要求，因此如果需要互操作性，发送方可以将证书视为自签名证书来构造。
特别是，以下字段描述证书的颁发者：
* issuer（[RFC5280] 第4.1.2.4节）
* issuerUniqueID（[RFC5280]第4.1.2.8节）
颁发者字段不是可选的，[X.509] 和 [RFC5280] 的第4.1.2.4节都禁止空颁发者，因此这样的值可能无法与现有应用程序互操作。
如果主题不为空，发送方可以将颁发者设置为主题，类似于构建自签名证书的方式。这在例如期望信任锚具有匹配的发行者和主题的应用程序中可能有用。然而，这是一个占位符值。未签名的证书不被视为自签名或自颁发。
发件人可以选择使用由单个相对可分辨名称组成的短占位符发行者，该名称具有类型为id-rdna-unsigned的单个属性和零长度UTF8String的值。id-rdna-unsigned定义如下：
id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 25 1}
该占位符名称在 [RFC4514] 的字符串表示形式中为：
1.3.6.1.5.5.7.25.1=#0C00
发送方必须省略IssuerUniqueID字段，因为它是可选的、不适用的，并且已被 [RFC5280] 的第4.1.2.8节禁止。
3.3、扩展
一些X.509扩展还描述了证书颁发者，因此对于未签名的证书没有意义：
* 权限密钥标识符（[RFC5280] 的第4.2.1.1节）
* 发行者替代名称（[RFC5280] 第4.2.1.7节）
发送方应该省略授权密钥标识符和颁发者备用名称扩展。 [RFC5280] 的第4.2.1.1节要求证书包含授权密钥标识符，但它允许在分发公钥时使用的自签名证书例外。本文档更新了 [RFC5280]，以允许在未签名的证书中省略授权密钥标识符。
一些扩展反映了主体是CA还是最终实体：
* 密钥用法（[RFC5280] 第4.2.1.3节）
* 基本约束（[RFC5280] 第4.2.1.9节）
发件人应该填写这些值以反映主题。那是：
* 如果主体是CA，它应该断言keyCertSign密钥使用位，并且应该包括将cA布尔值设置为TRUE的基本约束扩展。
* 如果主体是最终实体，则它不应该断言keyCertSign密钥使用位，并且它应该忽略基本约束扩展或将cA布尔值设置为FALSE。与自签名证书不同，未签名证书不会自行颁发，因此无需在任一扩展中容纳自签名。
4、使用未签名的证书
id-alg-unsigned类型的X.509签名始终无效：
* 在处理X.509证书而不验证签名时，接收方可以接受id-alg-unsigned。
* 验证X.509签名时，接收方必须拒绝id-algunsigned。
特别是，X.509验证器不得接受id-alg-unsigned来代替证书路径中的签名。
预计大多数未经修改的X.509应用程序将已符合本指南。因此，建议X.509应用程序通过忽略本文档并将id-alg-unsigned视为与无法识别的签名算法相同的方式来满足这些要求。未经修改的X.509验证器将无法验证签名（[RFC5280] 第6.1.3节的步骤（a.1）），从而拒绝证书路径。相反，在X.509应用程序忽略自签名的情况下，id-alg-unsigned也将被忽略，但效率更高。
在其他情况下，应用程序可能需要修改或将其自身限制为特定形式的未签名证书。例如，应用程序可能会检查自签名，以将本地配置的证书分类为信任锚或不受信任的中间证书。在使用未签名的证书作为信任锚之前，此类应用程序可能需要修改其配置模型或用户界面。
5、安全考虑
最佳实践是将每个加密密钥限制为单一用途。如果跨上下文重复使用密钥，则当两者使用发生冲突时，应用程序将面临跨协议攻击的风险。然而，在使用自签名最终实体证书的应用程序中，主体的密钥必须以两种方式使用：X.509自签名和最终实体协议。未签名的证书通过删除X.509自签名来修复此密钥重用问题。
如果应用程序接受id-alg-unsigned作为认证路径的一部分，或者在任何其他需要验证X.509签名的上下文中，签名检查将被绕过。因此，第4节禁止这样做，并建议应用程序将idalg-unsigned与任何其他以前无法识别的签名算法一样对待。不合规的应用程序存在类似于 [JWT] 和 [JOSE] 第1.1节中描述的漏洞的风险。
自签名证书中的签名是自签名的，因此在传达信任方面的用途有限。但是，某些应用程序可能会使用它作为完整性检查，以防止意外的存储损坏。未签名的证书不提供任何完整性检查。检查自签名完整性的应用程序应该使用其他一些机制，例如带外验证的外部哈希。
6、IANA考虑因素
6.1、模块标识符
IANA已在“SMI Security for PKIX Module Identifier”注册表中添加了以下条目（由 [RFC7299] 定义）：
表1
6.2、算法
IANA已将以下条目添加到“PKIX算法的SMI安全性”注册表 [RFC7299]：
表2
6.3、相对专有名称属性
为了分配id-rdna-unsigned，本文档为相对专有名称属性引入了一个新的PKIX OID弧：
IANA已将以下条目添加到“SMI Security for PKIX”注册表 [RFC7299]：
表3
IANA已在“管理信息结构（SMI）编号（MIB模块注册）”注册表组内创建了“PKIX相对可分辨名称属性的SMI安全性”注册表。
新注册表的描述为“iso.org.dod.internet.security.mechanisms.pkix.rdna（1.3.6.1.5.5.7.25）”。
新注册表具有三列，并使用以下值进行初始化：
表4
未来对该表的更新将根据 [RFC8126] 中定义的规范要求策略进行。
7、参考文献
7.1、规范性参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2、参考资料
[JOSE] Madden, N., "JOSE: Deprecate 'none' and 'RSA1_5'", Work in Progress, Internet-Draft, draft-ietf-jose-deprecate-nonersa15-03, 19 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-josedeprecate-none-rsa15-03>.[JWT] Sanderson, J., "How Many Days Has It Been Since a JWT alg:none Vulnerability?", <https://www.howmanydayssinceajwtalgnonevuln.com/>.[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, DOI 10.17487/RFC4158, September 2005, <https://www.rfc-editor.org/info/rfc4158>.[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, <https://www.rfc-editor.org/info/rfc4514>.[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, <https://www.rfc-editor.org/info/rfc5914>.[RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, <https://www.rfc-editor.org/info/rfc7299>.[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.[X.509] ITU-T, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO/ IEC 9594-8:2020, October 2019, <https://www.itu.int/rec/t-rec-x.509/en>.
附录A、ASN.1模块
该ASN.1模块使用 [RFC5912] 建立的约定。
SignatureAlgorithmNone { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algUnsigned-2025(122) }DEFINITIONS IMPLICIT TAGS ::= BEGINIMPORTS SIGNATURE-ALGORITHM FROM AlgorithmInformation-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ATTRIBUTE FROM PKIX-CommonTypes-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ;-- Unsigned Signature Algorithmid-alg-unsigned OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 36 }sa-unsigned SIGNATURE-ALGORITHM ::= { IDENTIFIER id-alg-unsigned PARAMS ARE absent }id-rdna-unsigned OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) rdna(25) 1 }at-unsigned ATTRIBUTE ::= { TYPE UTF8String (SIZE (0)) IDENTIFIED BY id-rdna-unsigned }END
致谢
感谢Bob Beck、Nick Harper和Sophie Schmieg审阅了本文档的早期版本。感谢Alex Gaynor提供了 [JWT] 的引用链接。感谢Russ Housley提供的额外意见。
***推荐阅读***
我们的WireGuard管理系统支持手机电脑了！全平台终端配置，支持扫码连接，一键搞定
保姆级教程：一条命令部署OpenVPN管理系统V4版，支持Win/Mac/安卓/iOS全平台接入
成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙
别再乱选VPN了！实测数据告诉你：为什么L2TP是个“坑”
终极进化：当swanctl遇上FRR，让你的Linux加密隧道化身SD-WAN雏形
流量指哪打哪！手把手教你用静态Segment List玩转SRv6流量工程
嫌SRv6报文太胖跑不动？带你在Ubuntu+FRR实战uSID微段压缩
22秒跑出密码！算力碾压再升级，揭秘WiFi6+WPA3的致命短板
嫌一键部署不过瘾？带你手搓Hermes智能体，主打一个通透
十倍性能提升！Ubuntu 26.04深度实测：当VPP遇上OpenVPN，带宽直接冲破 6.5Gbps！
性能暴涨670 %！当WireGuard遇上VPP，带宽直冲7.4 Gbps！
手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
2048卡昇腾910C集群算力集群交付工程手册
2048卡H100算力中心100G无阻塞存储网建设方案
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《未签名的X.509证书》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论