摘要

  • RIPE NCC 表示，其 RPKI API 已支持创建和管理 BGPsec 路由器密钥证书。
  • 证书授权与 ASN 关联的密钥；它不会让路由器自动签名，也不会让邻居自动验证路径。

BGPsec 曾有个很像柜台手续的问题：标准早就规定了路由器密钥证书该是什么样，运营商却还得想办法把签发流程塞进日常 RPKI 运维。RIPE NCC 现在通过 RPKI API 增加了这条路。证书申请和管理可以交给软件。路由器嘛，暂时还不能点一下就从机柜里长出来。

RIPE NCC 在 10 月 23 日的会员更新中宣布，RPKI API 支持创建和管理 BGPsec 路由器密钥证书。前一天，RIPE NCC 首席工程师 Tim Bruijnzeels 在 RIPE Routing WG 邮件列表中解释，ASN 持有人可以授权路由器密钥为 BGP 更新签名。公开的 BGPsec API 文档仍把接口指向 RPKI 试验环境 localcert.ripe.net，并说明如何创建密钥对象、取回证书及其证书链。这说明签发流程已有 API 能力，文档没有给出生产环境中已启用该功能的会员数量，也没有说明所有账户都能使用的正式端点。

这张证书的职责很具体。RFC 8209 把它定义为 RPKI 终端实体证书，将公钥绑定到一个或多个 ASN。路由器保管对应的私钥；支持 BGPsec 的设备在向外部邻居发送 BGPsec UPDATE 时，用它签署路径信息。接收端可以依据可用证书和签名检查这条签名路径。

它不替代其他 RPKI 对象。ROA 说明哪个 AS 可以起源一个前缀；ASPA 记录 AS 持有人授权的上游；BGPsec 则沿 AS 路径携带签名。Bruijnzeels 明确说三者互补。路由器密钥证书是路径签名机制中的一环，不是起源验证或路由泄漏检测的新名字。

RIPE NCC 工程师邮件里最有用的句子，不是宣布 API，而是承认硬件路由器支持还落在后面，渐进部署和性能也仍是难题。API 能减少一个环节的人工工作，却不能替路由器协商 BGPsec 会话，不能替机箱保护私钥，不能让对端读懂签名属性，更不会替运营商决定签名路径缺席时怎么办。

部署阶梯很清楚：申请证书；保护并安装私钥；在兼容路由器和会话上启用 BGPsec；发送签名 UPDATE；再由接收路由器验证。每一步都有不同的运维责任人。API 返回成功，只证明第一步完成。公开资料尚未列出面向所有会员的生产端点，也未说明哪些路由器实现已走完其余步骤。RIPE NCC 自己的工程师指出硬件支持滞后；下一条有用消息，应该回答这个问题。

对运营商来说，这仍是实质进展。证书签发属于控制面工作，API 让它有机会和其他 RPKI 任务一起自动化。真正有说服力的验证，是把证书、受保护的密钥、具体路由器、BGPsec 邻居和一条通过验证的 UPDATE 连起来。现在 API 让其中一个配置步骤更方便了；路径还不会自己签名。

来源：RIPE NCC 会员更新，2026 年 10 月 23 日；RIPE NCC 首席工程师 Tim Bruijnzeels，RIPE Routing WG，2026 年 10 月 22 日；RIPE NCC BGPsec API 文档；RFC 8209；RFC 8205；RIPE NCC 认证实践声明 RIPE-851。