2026 服务器租用自建私有 CA 证书服务：密钥保管/短有效期/OCSP 签发量避坑全解

自建私有 CA 的资源账，算下来是"签发很轻、停机很贵"

企业决定自建私有 CA 之后，紧接着要回答的问题是这台机器该怎么配。常见的估法是按"证书签发服务"去理解它，把注意力放在签名运算需要多强的 CPU、多大的内存上。真正跑起来几个月之后再回头看，多数团队会发现签发本身消耗极小，真正花钱花精力的是另外三笔账：私钥怎么保管、吊销状态怎么告诉给验证方、以及这台机器凭什么一直活着。

一次证书签发在技术上是这样一串动作：核验请求方提交的身份凭据、用中间 CA 的私钥对给定的证书内容做一次签名、写一条签发记录、更新一次状态索引。这里面唯一的密码学开销就是一次私钥签名运算，其余都是少量的文件与数据库写入。这个规模的工作，放在任何一台通用服务器上都不会让 CPU 有明显反应，瓶颈从来没有出现在这一步。

对照之下另外三笔开销才是主角。私钥保管决定了这台机器要不要配密码设备、要不要做双人到场的操作规范、备份要加密到什么程度、备份副本允许扩散到哪里；吊销状态分发决定了需要多少出口带宽、要不要前置缓存、要不要为在线查询准备常驻进程；高可用决定了要不要第二个站点、要不要做跨站点的状态一致性、多久演练一次恢复。这三样共同支撑起"CPU 很闲、可用性很贵"这个结论。

所以规划顺序应该反过来：先定能容忍多久的停机，再定私钥放在哪里，最后才轮到挑机型。本文就按这个顺序展开，并且严格区分两类信息——一类是可以查到、可以直接采信的协议与结构事实；另一类是只能靠自己压测校准的容量阈值。后者只给估算口径和测量方法，不给具体数值，也不推荐某一款具体产品。

内网双向验证、设备接入、研发内部服务、拿不到公网域名验证的环境，是私有 CA 的主场

判断要不要自建，先看信任方在谁手里。如果证书的使用者和验证者都在自己可控的范围内，公开 CA 的价值就近乎为零，因为它卖的核心是"被广泛预置的信任"，而这份信任在内网里根本用不上。反过来说，只要存在一个不在你控制范围内的验证方，自建的成本就会陡然上升。

典型场景之一是服务之间的双向 TLS。服务网格、远程调用框架、数据库连接要用客户端证书证明身份时，通信双方信任的是同一个签发者，而这个签发者只可能是自己的 CA。这类场景的特点是证书数量与服务实例数同阶、生命周期与实例同步、轮换频繁，天然适合自动化签发，也是各类开源 CA 方案最容易落地的一块。

第二种是设备与终端接入。产线工控机、门店终端、自助设备、边缘网关、物联网节点，每台设备烧进一张身份证书，上线时用这张证书向平台证明自己。特点是数量大、部署分散，相当一部分设备只能走受限通道甚至常年离线，证书一旦过期往往需要人工到现场处理，轮换代价极高。这一类对有效期设计和续期通道的要求，比服务端场景高得多。

第三种是研发体系内部。镜像仓库、制品库、流水线执行器、测试环境网关、内部包管理服务，这些系统对外不开放但内部权限复杂。用证书区分流水线身份比用长期口令更可控，因为证书天然带有效期、天然可以被吊销，也不需要集中维护一份随时可能泄露的口令清单。

第四种是拿不到公网域名验证的环境。公开 CA 的自动化签发普遍依赖域名验证，ACME（RFC 8555）定义的 HTTP-01、DNS-01 这类挑战都要求请求方在公网可达的地址上完成应答。完全隔离的内网、使用内部域名空间的解析体系、与公网剥离的工业生产网络，这些条件常常一条都满足不了。此时自建不是"更划算"的选择，而是唯一可行的选择。

对外站点和需要被广泛信任的场景，自建是负收益

边界其实很清楚：凡是验证方不属于你自己、且你无法要求对方预置你的根证书的场景，都不该自建。面向公众的网站、开放接口、给客户使用的客户端需要访问的端点，这些连接由浏览器、操作系统、移动端系统完成信任链校验，而它们的信任库里没有你的根。用户看到的是不受信任的警告，绝大多数人不会去点那一行不起眼的继续访问。

有人会问能不能让客户手动安装根证书。技术上能，但要清醒认识它的代价：你把信任边界的判断责任转移到了客户的安全团队身上，对方要评估你的根该不该装、装了之后它能签发什么、出事之后怎么干净地摘掉。这在少数长期深度合作的机构对接里可行，在任何开放场景都不可行。

现实的方案往往是两套并存而不是二选一：对外那一层继续用公开 CA 签发的证书，内部通信走私有 CA，两者在网关或边界代理处交接。这个切分位置要明确画进架构图，因为它决定了私有 CA 的签发范围上限，也决定了故障域的边界画在哪里。

还有一类不适合自建的情形与信任无关，与人力有关。如果团队没有专职运维、无法承担"密钥保管要有流程、要有双人、要有演练、要有人在半夜把它恢复起来"这套负担，那么自建引入的风险很可能大于它解决的问题。证书这件事的特点是平时毫无感知、出事就是一次性爆雷，缺少常态维护机制的组织最容易把它遗忘到出事为止。

有效期每压短一档，就把一份压力从安全侧搬到自动化侧

有效期是私有 CA 最重要的一个旋钮，它同时决定三件事：私钥泄漏后的可利用窗口、吊销机制的紧迫程度、以及续期系统的繁忙程度。压短有效期的收益很直接——证书连同私钥一起失窃之后，能被利用的时间上限就是剩余有效期；与此同时，因为证书很快到期，"什么都不做等它过期"本身成了一种可行的失效手段，缓解了吊销信息传播慢这个老问题。

账单在另一边。有效期压到天级，意味着每天要跑一遍全量续期；压到小时级，意味着续期链路必须全天候健康，任何一次中断都直接兑换成一批过期证书。这里出现了一次典型的置换：你把"吊销信息传播有延迟"这个旧问题，换成了"续期失败立刻影响业务"这个新问题。

能不能用短有效期，唯一的判断标准是续期全链路的可靠程度。这条链路包括：证书临近到期的检测、请求构造与身份认证、CA 的应答、证书回写与服务端的重新加载、失败重试与告警。其中最容易被忽略的是倒数第二步——大量程序在启动时读取证书文件，文件被替换之后进程并不知道，必须显式触发重载或者重启才能生效。这一环没做，证书其实已经更新了，但连接照样失败。

因此有效期不应该全公司统一。能够完整自动化的服务端环境压到天级甚至更短，配合进程内自动重载；续期能力弱的一侧——离线设备、固件老旧、只能人工触达的终端——放到月级或更长，并且在网络位置上与短有效期那部分隔离。用同一张策略表去管所有终端，是私有 CA 设计里最常见的失败起点。

还有一个必须做的兜底动作：无论有效期最终定多长，都要把"剩余有效期"当成一个持续观测的分布来看，而不是逐张证书地看。分布最左端的那个值才是你的实际容错时间，它通常比名义有效期短得多，因为证书的签发时刻天然是分散的。

根 CA 离线的三条可执行边界，比买什么介质更关键

层级结构是私有 CA 里少数可以直接采信的事实：一个自签名的根 CA，签发一到几个中间 CA，日常的终端实体证书由中间 CA 签发。这个结构存在的理由只有一个——压低根私钥的使用频率。根密钥只在新签中间、轮换中间、吊销中间时才会被用到，其余时间它可以完全不存在于任何在线系统之中。

边界之一是物理与网络上的隔离。所谓离线，不是"放在一台不常登录的机器上"，而是这台机器在完成那一次签发任务之后不再与生产网络连通。落到具体形态上，可以是专用设备，也可以是加密容器，做完即封存、介质多人分持。形态取决于组织规模，但有一条不可妥协：任何在线服务的文件系统里，都不允许存在一份随时可用的根私钥。这一条比买什么设备重要得多。

边界之二是启用过程本身要被固化下来。每一次动用根密钥，都应该是一次有明确步骤、有参与者、有留存记录的操作，行业里通常称之为密钥仪式。内容不必复杂：谁到场、按什么顺序做了什么、用了哪份脚本、产出了哪些文件、签字的记录放在哪里。写下来的意义主要不是应付检查，而是两年之后换人操作时，这套东西不会退化成"上次那个脚本放哪来着"。

边界之三是演练。根的使用频率极低，恰恰是它最危险的地方——一年动一次的流程，动的时候必然生疏、必然出岔子。把"从离线状态恢复出来、签发一个新中间、验证信任链可用"这件事定期做一遍，成本很低，收益是把不确定性提前暴露在没有业务压力的时刻。

层级结构真正的价值体现在可恢复性的不对称上。中间 CA 出问题时，可以在根上吊销它并用新的中间重新签发受影响的全部终端证书，信任锚不用动一下；根出问题时没有这一层缓冲，所有已签发的证书连同信任锚一起作废。整个设计的全部理由就在这句话里。

文件、密码设备、云密钥服务，差别在失窃半径与运维半径

中间 CA 的私钥总要落在某个地方，可选项是三个：加密存放的密钥文件、本地密码设备、云上的密钥管理服务。三者的差别不在"安全等级"这种笼统的说法上，而在三个可以具体讨论的半径上：谁能碰到私钥、丢了之后怎么找回、以及谁负责它一直可用。

密钥文件是最容易理解的一种。私钥加密后存在磁盘上，启动时输入口令或者读取解锁凭据。它的失窃半径等于"能拿到这份文件副本并且能拿到解锁凭据的人"，而备份、快照、配置仓库、容器镜像都可能成为这条路径上的环节；反过来它的恢复半径最小，复制回来就能用。对签发量不大、团队规模有限、管控边界清晰的环境，这个选项远没有通常被形容的那么糟糕，前提是备份路径被认真清点过一遍。

密码设备改变的是头一个半径：私钥在设备内部生成并且不出设备边界，签名运算在设备内部完成，主机拿到的只是结果。PKCS#11 是这一类设备的通用接口标准，CA 软件通过它调用设备能力，因此只要软件支持这个接口，后续替换厂商的成本就相对可控。代价落在后两个半径上——设备本身的冗余要单独规划，通常至少两台起；设备的运维需要专门知识；恢复流程不再是复制文件而是重新灌注密钥，操作失误往往不可逆。

云密钥服务是把第三个半径也外包出去：不用自己管硬件生命周期，权限、吊销、使用审计都由云平台提供。代价是引入新的依赖——从 CA 主机到该服务的网络连通与鉴权成为签发链路上的一环，跨可用区甚至跨地域的可用性需要单独评估，长期调用量也会随签发规模进入成本明细。

建议的判断顺序是：先把"离线根加在线中间"这套流程跑顺，把备份、演练、审计三件事做成习惯；只有当外部要求明确指向私钥不可导出，或者内部审计明确要求私钥不得出现在通用文件系统里时，才值得上硬件。跳过流程直接买设备，买到的往往是一份相当昂贵的不安全感。这里不比较具体产品，因为决定适配与否的是接口支持情况和运维能力，不是厂商名字。

日签发量的真实规模，通常比预估低一到两个数量级

先给一个可以直接套用的估算口径：稳态日签发次数约等于终端总数除以有效期天数，再乘一个覆盖重试、实例换新、临时扩容的放大系数。用这个口径感受一下量级——几千个工作负载、有效期为天级的环境，日签发落在数千到数万次这个区间；同样的节点数如果有效期放宽到季度级，日签发就掉到几十到几百次。这个粗算足以回答"要不要为签发单独配一台高主频机器"，答案通常是不需要。

但要非常清醒：稳态均值不是选型依据，峰值才是。如果所有终端都在同一个时间点触发续期——比如默认都在凌晨某一刻启动，或者都被同一个定时任务唤醒——那么一整天的签发量会挤在很短的窗口里打过来，瞬时并发可能是均值的几十倍。这是私有 CA 唯一真正可能遇到"忙不过来"的时刻，而它本质上是一场排队事故，不是算力瓶颈。

解决它不需要加机器，需要错峰。让每个终端在发起续期之前加一段随机抖动，把续期动作摊到有效期的更前段，峰值会立刻塌下来；服务端再配上限流与排队队列，让突发请求排在队列里，而不是把签发进程压垮。这里有一个容易出错的细节：抖动不能依赖固定种子的伪随机算法，如果所有节点共用同一种子，错峰直接失效，看起来随机实际是齐刷刷的。

另一件需要提前算清楚的账是存储增长。每一张签发的证书都要留档，再加上签发记录、轮换记录、吊销记录，年增量按"日签发数乘以单条记录大小再乘以三百六十五"估算。这条曲线在头一年几乎看不出问题，到第三年开始影响备份窗口和存储开销，宜早留余量。

压力集中在三个位置：续期尖峰、吊销列表体积、在线状态查询量

把前面拆出来的东西合起来看，会得到一个相当一致的形状：私有 CA 的压力几乎全部落在分发与状态查询上，几乎没有一处落在密码学运算上。这个判断直接决定了选型时该看什么指标——看内存与磁盘 IO、看网络出口质量、看能不能在这一层前面加缓存，而不是看主频和核心数。

三个压力点的面貌各不相同。续期尖峰是突发型负载，特征明显、容易观测，用错峰加队列基本可以压下去。吊销列表是慢性负载，随着吊销条目累积持续变重，不容易被注意到，往往在某个节点上突然变成可见的带宽或解析开销。在线状态查询是持续型负载，它与业务的握手频率绑定，业务涨它就涨，而且必须实时应答。

三者之间还存在耦合。有效期压得越短，因为轮换而产生的新连接越多，在线状态查询的请求量随之上涨；有效期短又意味着必然依赖自动续期，续期尖峰的绝对值也跟着上涨。所以"把所有证书都设成很短的有效期"并不是一个纯粹的优化动作，它把压力从吊销列表这一侧搬到了在线查询和续期这一侧。

因此不建议在任何未实测的前提下拍板容量指标。合理的做法是给这三个量分别建立一条随时间变化的曲线，每个季度回看一次斜率。斜率决定是否扩容，绝对值决定当前起步配置，两者混在一起看，容易得出又贵又不稳的方案。

CRL 是一份会持续长大的文件，麻烦出在分发而不是生成

CRL 即证书吊销列表：CA 按固定周期把所有尚未过期但已被吊销的证书序列号汇总成一份带签名的文件，供验证方下载之后逐个比对。它的生成开销可以忽略不计，真正的问题是体积随吊销条目线性膨胀，而每一个验证方都可能要去拉取完整的那一份。

"完整的"这三个字正是症结所在。验证方通常需要先把整份列表取到本地再解析并缓存，条目越多单次下载体积越大，传输耗时与解析开销同步上涨。对常年在线的服务端来说问题不大，对带宽或算力受限的终端——尤其是前面提到的工控设备与物联网节点——体积增长会直接表现为可感知的设备负担。

第二个影响因素是发布间隔。为了让吊销更快生效，人们倾向于缩短间隔；间隔一短，这份越变越大的文件就要被拉取得越频繁，带宽消耗近似可以用"体积除以间隔"来理解。这里存在一个明确的替代关系：要么接受吊销状态传播得慢一些，要么承担更高的分发开销，两者不可兼得。

压低这份开销最有效的办法不是优化文件格式，而是压低吊销率。如果绝大多数失效的证书是靠"到期自动失效"退场的，而不是靠显式吊销，那么列表的增长速度会非常慢。这恰好与短有效期的思路呼应：有效期越短，越多失效不需要进入列表，列表就越瘦。增量式列表与按范围分片是另外两种工程手段，思路都是把一份大列表切成若干小份，只取需要的那一小份。

需要实测的三项是：在你的证书模板下，单条吊销条目占多少字节；列表增长到多少条之后，设备侧的拉取开始影响其自身业务；多长的发布间隔能把吊销生效时间控制在可接受范围内。这三项都依赖具体的证书字段，扩展项、吊销原因码、序列号长度都会改变结论，所以必须用你自己的模板生成一批样本去测，拿别处的数字套过来没有意义。

在线状态查询把可用性要求抬了上来，而软失败会掩盖故障

OCSP 是在线证书状态协议（RFC 6960），思路与吊销列表相反：不再让验证方下载全量列表，而是由验证方针对某一张具体的证书向响应服务发一个查询，问这个序列号现在是什么状态，拿回一个带签名的应答。这种做法解决了列表体积的问题——应答大小与被吊销证书的总数无关，每次只回答一张。

代价是把一份静态文件的分发依赖，换成了必须实时应答的服务依赖。列表发布之后，紧接着的整个缓存周期都不需要 CA 在线；在线查询则是请求来了就必须答。答不上来的后果取决于客户端的校验策略，多数实现采用软失败：拿不到状态信息就不因为没有状态信息而拒绝连接。这在可用性上是好事，在安全性上是明显的折扣——响应服务长期不可用时，吊销检查实际上被静默跳过了。

由此引出一个容易被漏掉的运营项：软失败会掩盖故障。响应服务挂掉之后业务照常运行，监控图上没有任何异常，直到某次例行核验、或者某次吊销真的需要生效时，才发现这条链路已经失效了很久。正确的做法是把响应服务的可用性、响应码分布、签名应答生成失败数做成独立告警，而不是等业务侧的报错来发现它。

请求量的估算口径是"握手频率乘以每次握手带来的查询次数"。短有效期会抬升握手频率，因为轮换会带来新一轮连接建立；峰值通常出现在批量上线、集中重启、以及网络抖动恢复之后的重连风暴。这个量必须由自身业务实测校准，这里不给具体数字，但可以给一个判断方向：当在线设备规模达到万台以上并且都按约定按时查询时，签名应答的生成开销就已经值得单独拎出来看了。

应答本身需要签名，通常由一张用途受限的委托签名证书完成，而不是直接使用 CA 私钥。好处是把高频签名操作与长期密钥隔离开来，委托证书可以设很短的有效期并频繁轮换。这是一个相当标准的做法，值得在规划阶段就写进方案，而不是上线之后再补。

OCSP stapling 省掉的是客户端那一跳，不是 CA 那一跳

stapling 的做法是：由被访问的服务器自己去向响应服务取一份针对自身证书的应答，在握手时把它连同证书一起发给客户端，客户端因此不必再自己去查询。对应的机制是 TLS 中定义的证书状态请求扩展（RFC 6066）。

收益有三条。客户端少一次外部往返，握手更快也更稳；访问者的行为不再暴露给响应服务方，隐私状况得到改善；更重要的一条是响应服务的请求量从"每个客户端一次"变成"每台服务器每个 stapling 有效期一次"，量级上通常有数量级的下降。对设备规模大、连接建立频繁的环境，这一条几乎是应当默认开启的选项。

代价也并不含糊。它给服务端增加了一项周期性任务：要持续去取新的 stapling，取不到就只能用旧的，旧的失效之后 stapling 静默失去作用，而且往往没有任何告警提示。另一方面，stapling 自身的生命周期决定了吊销信息的最坏传播时延，取回的间隔越长，一张已经被吊销的证书还能被信任的时间就越久。

必须澄清一个常见误解：stapling 并不会降低 CA 的可用性要求。服务端仍然要去响应服务取应答，响应服务不可用时服务端也拿不到新的 stapling，只是这块影响被推迟到了 stapling 过期那一刻。它降低的是请求量与终端感知延迟，不是可用性依赖本身。

在纯内网、两端都可控的场景里，还有一个更朴素的选项值得考虑：既然吊销率通常很低、节点又都在自己的管理之下，那就接受列表式分发，或者把状态信息通过内部配置通道下发，让短有效期承担主要的失效职责。少一个在线组件，就少一个半夜要爬起来抢修的东西。要不要这么取舍，取决于你能接受多长的"吊销到真正生效"之间的时延。

CA 停机不会立刻发作，这才是它最难对付的地方

已经签发的证书在有效期内继续可用。验证方校验的是本地信任锚、有效期，再加上可选的吊销状态，通常不需要实时联系签发者。这个特性带来一个反直觉的结果：CA 挂掉之后的一段时间里，业务完全没有感知。

感知出现在边界上。停机时长一旦越过最短那批证书的剩余有效期，就会有一批证书因为拿不到替换而过期，表现为握手失败、连接被拒，随后是应用层重试引发的连锁反应。这是典型的延迟爆炸型故障：故障真正发生的时刻与故障被感知的时刻之间，隔着整整一个证书有效期。

这个特性决定了应该监控什么。盯着"进程在不在、端口通不通"远远不够，因为你真正想知道的是距离爆炸还有多久。更有效的四个指标是：当前存活证书剩余有效期的最小值与整体分布、最近一次成功续期距今多久、续期失败率的移动均值、以及续期队列的积压长度。其中第二个最灵敏——续期是每天甚至每小时都在发生的事，一旦它停了，几乎可以立刻察觉。

高可用设计上有一件容易被搞错的事：CA 并不是一个可以随意多副本的无状态服务。它持有一把不能随便扩散的私钥，也持有必须唯一的签发状态。做多站点部署时要先想清楚两件事——两侧使用的是不是同一份私钥（如果是，失窃半径也随之扩大到了两个站点），以及签发状态如何在站点之间保持一致（如果序列号自增或状态表各自独立，两侧会签出互相冲突的结果）。

灾难恢复的核心不是备份本身，而是"从备份恢复出来真的能用"。建议定期把备份恢复到一个隔离环境里，完整走一遍签发、吊销、状态查询三个动作，把耗时记下来作为真正出事时的恢复时长基线。没有演练过的备份，在统计意义上等同于没有备份。同时把恢复步骤写成照着就能执行的文档，因为真正出事时的执行者，往往是没做过这件事的人。

时钟漂移能把一张刚签好的证书变成一张过期证书

证书里写着生效时刻与失效时刻，验证方的判断完全基于自己的本地时钟。整个体系里没有任何一处会去核对"现在到底几点"，所以时钟不是辅助条件，而是正确性的一部分。

偏移的后果分三种。签发侧时钟超前，签出来的生效时刻落在未来，验证方会认定这张证书尚未生效；签发侧时钟落后，失效时刻已经落在过去，于是出现"签发即过期"的诡异情形——证书内容看起来一切正常，但每一次握手都失败。验证侧偏移同理，只是表现更随机：不同节点的偏移方向不同，于是形成"这几台能连、那几台连不上"的疑难杂症，排查起来非常耗时。

短有效期把这个敏感度放大了。有效期为一年的证书容忍几十秒的漂移毫无问题；有效期为一天甚至几小时的证书，同样量级的漂移就占到有效窗口的可观比例，偏移稍大就直接越界。这也是为什么在把有效期压短之前，必须先把时钟治理做完。

具体要做的事不多：所有参与签发与验证的机器统一使用同一批时间源，逐级监控与时间源的偏移量，把偏移做成带阈值的告警，而不是只看服务在不在。虚拟化环境要额外小心，虚拟机的时钟可能在宿主机高负载、快照恢复、热迁移之后发生跳变，这类环境的时钟偏移应当单独看一条曲线。

还有一个容易被忽略的点：机器重启过程中，如果时间同步服务尚未就绪就先把 CA 拉起来了，那么重启之后的首次签发有可能是建立在错误的时间基线上的。把时间同步服务配置成 CA 进程的强依赖，可以规避这一类只在重启之后才偶发出现的事故。

签发留痕的存储账与检索账要分开算

审计要回答的核心问题是"这张证书从哪来"。具体需要落地四条信息：谁发起的请求、什么时间、签给谁（主题与备用名称）、用哪一把中间签发的。再加一条可选但强烈建议留存的记录：签名动作本身——也就是密码设备或者云密钥服务侧的操作日志，它记录的是"私钥被用了一次"，与应用层的签发日志互为印证。

留痕的价值平时近似为零，在事故时变为全部。当有人拿着一张来路不明的证书问"这是正式签发的还是有人绕过了流程"、当需要确定某一批受影响证书的完整清单、当需要在几千张证书里找出所有发给某个特定服务的那些，没有记录就意味着唯一可行的兜底是全量轮换。而全量轮换在还能自动化的服务端尚可承受，在那些必须人工触达的设备上，可能等于一次集体上门。

存储账很好算：年增量约等于日签发次数乘以单条记录大小再乘以三百六十五，再加上索引开销。真正难的是检索账。把日志塞进某个存储系统很容易，难的是几个月之后要在里面按"某个名称在过去十二个月里被签过几次"这类条件查询。规划时就要想清楚查询维度有哪些、要不要建倒排、热数据与冷数据分别保留多久、归档到哪一层。

留存期内的数据完整性也要在设计阶段考虑，按追加方式写入、异地保留副本、对历史批次做链式校验，都是可行的做法。另一个容易被忽视的点在于日志自身的敏感度：主题名称与备用名称会暴露内网的服务清单和命名规律，因此访问这些日志的权限应当与访问 CA 主机的权限同等看待，而不是当作普通应用日志随手共享出去。

小团队内网、多站点设备接入、对外签发三种形态各自该盯什么

同样是自建私有 CA，不同形态关心的指标完全不同。先看小规模形态：内部双向验证的节点在几十到几百之间，几乎全在自己的管理网络里，证书按天或者按周轮换。这一层基本不受规格约束，关键是别把它随便搭在一台同时跑着其它业务的机器上——那样出事时它会跟那些业务一起被重启。对它来说，备份能不能落到本机之外、时间源能不能稳定访问，比 CPU 和内存重要得多。

再看多站点设备接入：设备规模从几千到几万，分散在不同地域的网络里，很多设备长期在线但通道质量一般，还有一部分常年离线。这一层的关键词从"算力"换成了"分发"——吊销列表或在线查询要不要前置缓存、要不要按地域就近部署，出口带宽需求可以按"设备拉取频率乘以单次体积"粗估。要单独评估的一件事是签发端能不能支持离线批量签发：对那些根本没有在线申请通道的设备来说，这条路是唯一的选择。

第三种形态是对外提供签发能力，也就是把这套服务开放给客户或合作伙伴的请求方使用。此时请求方的行为不再可控，请求量既可能有突发也可能被滥用，因此关注点变成限流与排队能力、异常请求的识别、多可用区部署，以及一条原则性的要求：在密钥和网络两个维度上与自身资产做隔离。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。把上面三层涉及的关键取舍汇总成下表，"主要代价"一列读出来的就是各自真正的账单。

哪些是能直接采信的结构事实，哪些必须自己测

把边界再明确一次。可以直接采信的机制事实是这样一份清单：私有 CA 的层级结构——根自签名、签发少量中间、中间负责日常签发，根的使用频率极低因而可以离线保存；ACME（RFC 8555）是用于自动化签发与验证的协议标准，通过挑战应答完成对控制权的证明；CRL 是 CA 定期发布的吊销证书清单，OCSP（RFC 6960）是针对单张证书进行在线状态查询的协议；stapling 由服务端代客户端获取状态并在握手中附带；证书有效性判断依赖本地时钟；PKCS#11 是密码设备向外提供能力的通用接口标准。这些都是写在标准文档里、不随环境改变结论的内容。

必须靠自身实测校准的是另一份清单：日签发量与峰值并发、单次签名的实际耗时、吊销列表体积随条目的增长斜率、在线状态查询的峰值请求频率与对应出口带宽、一年的日志存储增量、以及从备份完整恢复所需的时间。这些量与密钥类型、密钥长度、证书模板里的扩展字段、设备数量、业务握手频率都有关，任何跨环境借来的数字都不可靠。

测量方法统一给三条。其一是固定变量：测量之前先把证书模板、密钥算法与长度、扩展字段全部锁定，中途不再改动，否则前后数据不可比。其二是覆盖周期：采样窗口至少完整覆盖一个业务周期，包含周峰、月末结算、集中发版日，只看一天的均值或者只看一天的峰值，都会得出错误结论。其三是分别记录均值与峰值：容量规划看峰值，成本核算看均值，两者混在一起得出的配置往往既贵又不稳。

最后一条建议是：这套东西先跑在一个可以随时推倒重来的环境里。私有 CA 的问题往往几个月后才显现，列表体积、时钟漂移、续期重试，都是慢变量。用预发布环境或者小规模的真实环境跑满两个完整的证书生命周期，比在纸面上把参数推演十遍更有说服力。

把这些判断落到具体机型之前，还要先确认三件事

其一，最短有效期定到多少。这个数字可以直接换算成可容忍的停机时长——允许的停机时间必须显著小于最短有效期减去人工介入所需的时间，并且留出余量。它决定的是要不要第二个站点、要不要跨地域部署、以及备份恢复的目标时长该压到多少。

其二，吊销状态用什么方式发布出去。以吊销列表为主就去看出口带宽与前置缓存能不能撑住，以在线查询为主就去看常驻进程的可用性与峰值请求承载力，两者并行就把两套一起算。这个答案决定的是机器网络侧的指标，而不是 CPU。

其三，私钥放在哪里。密钥文件、密码设备还是云密钥服务，这个答案决定要不要专用的接口和驱动、要不要额外的冗余单元、以及备份长得什么样。它也决定了恢复演练具体要演练哪些步骤。这三个问题没有答案之前讨论机型规格，得出的配置与实际需求通常关系不大；把这三份答案带进选型对话里，讨论会立刻具体起来。

一万网络的交付边界与验收口径

先说清楚边界。我们交付的是基础设施层：算力、内存、存储与输入输出能力、网络接入与出口带宽、机房侧的电力与环境条件，以及与之配套的可用性保障。私有 CA 这一层的软件栈、密钥保管策略、证书模板设计、吊销策略与相应的制度流程，属于客户侧的职责范围，我们不宜越界替客户决定——尤其像根密钥保管方式这样的决策，必须由客户自身的安全口径来确定。

再讲可以验收的部分。以下几项与上层的具体方案无关，可以在交付时实际验证：到客户指定外部时间源的网络连通与时间同步状况；磁盘与写入 IO 能否满足目标签发速率下的持续写盘；网络出口到客户目标地域的连通质量与实际可用带宽；跨可用区或不同宿主资源池的分布能力；快照与备份机制的可用性以及实际恢复耗时。这几项都可以在上线之前用一套测试签发流程完整地跑一遍。

最后是口径纪律。文中所有涉及容量与阈值的表述都是估算口径，不构成任何性能保证；具体机型、带宽与报价以官网实时信息或咨询确认为准。我们也不对上层业务的运行结果作出承诺，因为它在很大程度上取决于前文列出的那些设计与运维选择。比较稳妥的路径是：先以较小规模形态把签发、续期、吊销、恢复这个闭环跑通，用实测出来的几个数字再决定是否扩容或调整部署形态。