Microsoft 允许 CA 使用下一代密码术 (CNG)，并建议不支持此套件的客户端出现不兼容问题。
这是 2008 R2 CA 的默认加密设置的图像。这台机器是一个非域连接的独立 CA：
这是已安装的提供程序。CNG 供应商标有 # 号
我的意图是拥有一个通用的离线 Root-CA，然后是几个服务于特定目的的中间 CA（MSFT-only vs Unix vs SmartCards 等）
有效期为 5 年、10 年和 15 年的根证书的理想设置是什么？
由于这是一个 RootCA，是否有任何参数会影响低功耗 CPU（移动设备）
注意：这是 Microsoft、NIST 和其他备受推崇的 PKI 和密码学专家所说的各种建议和行动的（非常长的）纲要。如果你看到一些需要哪怕是最轻微的修改的东西，请告诉我。
在我开始配置 CA 及其子系统之前，很高兴知道即使 MSFT 的 CryptoAPI 需要自签名根，一些非 MSFT 软件可能遵循 RFC 3280 并允许任何 CA 成为受信任的根以进行验证。一个原因可能是非 MSFT 软件更喜欢较短的密钥长度。
以下是有关设置 CA ROOT 和 Subs 的一些配置说明和指南：
存储 CA 的私钥
最佳：将密钥存储在支持密钥计数的 HSM 上。每次使用 CA 的私钥时，计数器都会增加。这可以改善您的审计配置文件。寻找 FIPS140 3 级或 4 级
好：将私钥存储在智能卡上。虽然我不知道有任何智能卡提供按键计数，但启用按键计数可能会在事件日志中给您带来意想不到的结果
可接受：将私钥存储在 Windows DPAPI 中。确保这些密钥和密钥注册代理不会最终出现在Roaming Credentials中。另请参阅：如何枚举 DPAPI 和漫游凭据
密钥长度
不要使用 1024 作为密钥长度... NIST 在 2011 年将其淘汰，MSFT 永远不会将其添加到您的受信任的根 CA 存储中，因为它不符合最低可接受的技术标准。
支持旧版应用程序的根 CA不得大于 2048 位。原因：MSFT 支持看到许多Java 应用程序或网络设备仅支持 2048 字节的密钥大小的情况。将较高的位长度保存到受限于特定用途（Windows 与网络设备）等的 CA。
NIST推荐 2048 或 3072 位。 支持 ECC，但它可能会导致设备互操作性问题。
计划在整个 PKI 中尽可能使用最强的加密（密钥长度），否则会带来混合的安全优势。
移动客户端存在问题（高 CPU）或与大密钥不兼容
到期
算法和密钥长度可能会影响您希望证书的有效期，因为它们有效地确定了攻击者破解可能需要多长时间，即密码学越强，您准备的证书有效期就越长
一种方法是确定最终实体证书所需的最长有效期，将其加倍以用于颁发 ca，然后再将其加倍以用于根 ca（在两层中）。使用这种方法，您将在每个 ca 证书达到其生命周期的一半时定期更新它 - 这是因为 ca 无法颁发到期日期晚于 ca 证书本身的证书。
合适的值只能由您的组织和安全策略确定，但通常根 ca 的证书寿命为 10 年或 20 年。
如果您担心兼容性，请将到期日期设置为 2038 以下。这是由于系统将数据编码为自 1970 年 1 月 1 日以来的秒数，并使用有符号的 32 位整数。在此处阅读有关此问题的更多信息。
选择哈希
您可能想模仿联邦 PKI 管理机构并设置两个 PKI 根。一种适用于所有支持它的设备的现代 SHA-256，以及一种旧版 SHA-1。然后使用交叉证书在两个部署之间进行映射。
尤其：
Windows 2003 和XP 客户端可能需要 SHA2 算法的补丁，其中包括 SHA256、SHA384 和 SHA512。查看更多技术信息
XP 或 2003 不支持使用 SHA2 散列的 Authenticode 和 S/MIME
“关于 SHA-224 支持，SHA-224 提供的安全性低于 SHA-256，但占用的资源量相同。此外，协议和应用程序通常不使用 SHA-224。NSA 的 Suite B 标准也不包括它。” 来源
“如果您计划让 XP 信任证书、验证证书、在链验证中使用证书或从 CA 接收证书，请不要在 CA 层次结构中的任何地方使用 SHA2 套件。即使 XP SP3 允许验证那些在 CA 层次结构中使用 SHA2，并且 KB 968730 允许有限注册由 CA 使用 SHA2 签名的证书，任何离散签名的使用都会完全阻止 XP。” （来源）
选择加密提供程序
启用随机序列号生成
从 2012 年起，如果您使用 MD5 作为哈希，则需要这样做。使用SHA1 或更高版本仍然是一个好主意。另请参阅此 Windows 2008R2“操作方法”以获取更多信息。
创建证书实践声明
证书实践声明是 IT 用于管理其颁发的证书的实践的声明。它描述了组织的证书策略如何在组织的系统架构及其操作程序的上下文中进行解释。IT 部门负责准备和维护证书实践声明。（来源）
注意：在某些情况下，例如在绑定合同上使用数字签名时，证书实践声明也可以被视为关于所提供的安全级别以及用于建立和维护安全级别的保障措施的法律声明.
如需帮助编写 CPS 声明，请参阅Microsoft 制作的“Job Aid”
最佳实践：尽管可以将自由格式的文本放入此字段（见notice下文），但理想的解决方案是使用 URL。这允许在不重新颁发证书的情况下更新策略，它还可以防止证书存储不必要的膨胀。
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.microsoft.com/policy/isspolicy.asp"
证书政策
也称为颁发策略或保证策略（在 MSFT 中），这是一个自定义的 OID，描述了应该放入证书中的信任量（高、中、低等）。 有关如何正确使用此字段的信息，请参阅此 StackExchange 答案。
确保应用程序策略和 EKU 策略匹配
应用程序策略是可选的 Microsoft 约定。如果您要颁发的证书同时包含应用程序策略和 EKU 扩展，请确保这两个扩展包含相同的对象标识符。
启用 CRL 检查
通常，Windows Server 2003 CA 将始终在颁发最终实体证书之前检查 PKI 层次结构中的所有证书（根 CA 证书除外）的吊销。要禁用此功能，请在 CA 上使用以下命令，然后重新启动 CA 服务：
certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
CRL 分发点
根 CA 的特别指南
这在根 CA 中是可选的，如果操作不正确，可能会暴露您的私钥。
所有 CRL 发布都是从离线 RootCA 到所有其他子 CA 的手动完成的。另一种方法是使用音频电缆来促进从根到子 CA 的单向通信
让根 CA 为从属 CA 颁发的每个证书颁发不同的 CRL 位置是完全可以接受的。
如果两个 PKI 相互信任并且完成了策略映射，那么在根中使用 CRL 是最佳实践。这允许吊销证书。
让 CRL “正确”非常重要，因为每个应用程序都需要进行 CRL 检查。例如，域控制器上的智能卡登录始终强制执行吊销检查，如果吊销检查无法执行或失败，则会拒绝登录事件。
注意 如果链中的任何证书无法验证或被发现被吊销，则整个链将采用该证书的状态。
自签名根 CA 不应列出任何 CDP。大多数 Windows 应用程序不启用 CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT 标志，因此忽略 CDP（这是默认验证模式）。如果启用该标志，并且自签名根证书的 CDP 为空白，则不会返回错误。
不要使用 HTTPS 和 LDAPS。不再支持将这些 URL 作为分发点引用。原因是 HTTPS 和 LDAPS URL 使用可能会或可能不会被撤销的证书。使用 HTTPS 或 LDAPS URL 时，吊销检查过程可能会导致吊销循环。要确定证书是否被吊销，必须检索 CRL。但是，除非确定 HTTPS 或 LDAPS 使用的证书的吊销状态，否则无法检索 CRL。
考虑使用 HTTP 而不是 LDAP - 尽管 AD DS 允许将 CRL 发布到林中的所有域控制器，但实施 HTTP 而不是 LDAP 来发布吊销信息。只有 HTTP 允许使用ETag和Cache-Control: Max-age标头，为代理提供更好的支持和更及时的撤销信息。此外，HTTP 提供更好的异构支持，因为大多数 Linux、UNIX 和网络设备客户端都支持 HTTP。
不使用 LDAP 的另一个原因是撤销窗口要小一些。使用 AD LDAP 复制 CA 信息时，吊销窗口不能小于 AD 中所有站点获取 CA 更新的时间。通常，这种复制可能需要长达 8 小时……也就是说，在智能卡用户的访问权限被撤销之前需要 8 小时。'Todo: 新推荐的 CRL 刷新时间是：???????`
使所有 URL 高度可用（也就是不包括外部主机的 LDAP）。Windows 将使验证过程减慢最多 20 秒，并至少每 30 分钟重试一次失败的连接。我怀疑即使用户没有积极使用该网站，预取也会导致这种情况发生。
监控 CRL 的大小。如果 CRL 对象太大以至于 CryptoAPI 无法在分配的最大超时阈值内下载对象，则会返回“撤销离线”错误并终止对象下载。
注意：当使用 Windows 2003 / IIS6 时，通过 ETAG 支持的 HTTP 分发 CRL 可能会导致 IE6 出现问题，其中 TCP 连接会不断重置。
Microsoft CA 不会将“Freshest CRL”扩展名放入已颁发的证书中。但是，可以将“Freshest CRL”扩展添加到已颁发的证书中。您必须编写代码将其添加到请求中、编写自定义策略模块或用于certutil –setextension待处理的请求。有关高级证书注册的详细信息，请参阅Microsoft 网站上的“高级证书注册和管理”文档
警告 如果在 CA 上启用了增量 CRL，则必须检查基本 CRL 和增量 CRL 以确定证书的吊销状态。如果两者之一或两者都不可用，则链接引擎将报告无法确定吊销状态，并且应用程序可能会拒绝证书。
CRL 大小调整和维护（CRL 分区）
对于每个被吊销的证书，CRL 将增加 29 个字节。因此，当证书达到其原始到期日期时，将从 CRL 中删除已撤销的证书。
由于更新 CA 证书会导致生成新的/空白 CRL，颁发 CA 可能会考虑每 100-125K 证书使用新密钥更新 CA，以保持合理的 CRL 大小。该发行编号是基于大约 10% 的已发行证书将在其自然到期日之前被吊销的假设。如果您的组织的实际或计划撤销率更高或更低，请相应地调整密钥续订策略。 更多信息
如果到期时间超过 1 年或 2 年，还应考虑更频繁地对 CRL 进行分区，因为撤销的可能性会增加。
这样做的缺点是增加了启动时间，因为每个证书都由服务器验证。
CRL 安全注意事项
如果使用 CRL，请不要使用 MD5 签署 CRL。向 CRL 签名密钥添加随机化也是一个好主意。
权限信息访问
如果证书不驻留在本地计算机上，此字段允许证书验证子系统根据需要下载其他证书。
自签名根 CA 不应列出任何 AIA 位置（请参阅此处的原因）
对于证书链中的每个证书，AIA 扩展中最多允许有五个 URL。此外，还支持整个证书链最多 10 个 URL。添加了对 URL 数量的限制，以减少在拒绝服务攻击中可能使用“权威信息访问”引用。
不要使用 HTTP S和 LDAP S。不再支持将这些 URL 作为分发点引用。原因是 HTTPS 和 LDAPS URL 使用可能会或可能不会被撤销的证书。使用 HTTPS 或 LDAPS URL 时，吊销检查过程可能会导致吊销循环。要确定证书是否被吊销，必须检索 CRL。但是，除非确定 HTTPS 或 LDAPS 使用的证书的吊销状态，否则无法检索 CRL。
启用 OCSP 验证
OCSP 响应者通常位于：http://<fqdn of the ocsp responder>/ocsp. 此 url 需要在 AIA 中启用。 请参阅适用于 Windows 的这些说明。
请知道默认情况下，完整的 OCSP 验证是关闭的（尽管根据规范它应该为 EV 证书“打开”）。此外，启用 OCSP 检查确实会增加初始连接的延迟
更安全的系统将希望在客户端或服务器端启用 OCSP 监控
OCSP 缓存持续时间
所有 OCSP 操作都通过 HTTP 协议发生，因此受典型 HTTP 代理缓存规则的约束。
具体来说，Max-age标头定义了代理服务器或客户端在使用条件 GET 确定对象是否已更改之前缓存 CRL 或 OCSP 响应的最长时间。使用此信息配置 Web 服务器以设置适当的标头。在此页面上的其他地方查找针对此的 AD-IIS 特定命令。
在颁发的证书中定义策略
父 CA 定义是否允许来自子 CA 的 CA 证书策略。当发行者或应用程序策略需要包含在子 CA 中时，可以定义此设置。
示例策略包括用于智能卡、身份验证或 SSL/服务器身份验证的 EKU。
请注意没有Certificate Policies扩展名的证书，因为它会使策略树复杂化。有关更多信息，请参阅 RFC 5280
知道策略映射可以替换路径中的其他策略
有一个特殊的策略叫做anypolicy改变处理
有一些扩展会改变anypolicy
如果您使用证书策略，请务必将它们标记为critical否则计算为valid_policy_tree空，将策略变成美化评论。
监控 DN 长度强制执行
OU 字段的原始 CCITT 规范说它应该限制为 64 个字符。通常，CA 对所有请求的证书主题扩展实施 x.500 名称长度标准。深 OU 路径可能会超出正常长度限制。
交叉证书分发点
此功能有助于环境需要安装两个 PKI，一个用于不支持现代加密的旧硬件/软件，另一个用于更现代的目的 PKI。
限制 EKU
与 RFC 5280 相比，“一般来说，[原文如此] EKU 扩展只会出现在最终实体证书中。”对 CA 密钥的使用施加限制是个好主意。
典型的独立 CA 证书将包含创建数字签名、证书签名和 CRL 签名作为密钥值的权限。这是 FLAME 安全问题的一部分。
MSFT 智能卡实施需要以下任一 EKU 和可能的修补程序
它在验证 EKU 方面也有一些有趣的限制（链接待定）。
如果您对任何 EKU 限制感兴趣，您应该看到这个关于 OID 的答案和这个关于约束证书的答案
谨慎使用基本约束“路径”
基本约束应描述证书是否为“最终实体”。向中间 CA 添加路径约束可能无法按预期工作，因为它是一种不常见的配置，并且客户端可能不会遵守它。
中间 CA 的合格从属
授权密钥标识符/主题密钥标识符
注意 如果证书的 AKI 扩展包含 KeyID，CryptoAPI 要求颁发者证书包含匹配的 SKI。这不同于 RFC 3280，其中 SKI 和 AKI 匹配是可选的。（待办事项：为什么有人会选择实现这个？）
为 Root 和 CA 取一个有意义的名称
人们将在导入证书、查看导入的证书和故障排除时与您的证书进行交互。MSFT 推荐的做法和要求是根有一个有意义的名称来标识您的组织，而不是像 CA1 这样抽象和常见的名称。
下一部分适用于因特定目的而受到限制的中间/子 CA 的名称：身份验证 vs 签名 vs 加密
令人惊讶的是，如果您使用 S/MIME 或数字签名（等），不了解 PKI 细微差别的最终用户和技术人员将与您选择的服务器名称进行交互的频率比您想象的要多。
我个人认为将颁发证书重命名为更用户友好的名称是一个好主意，例如"Company Signer 1"我一眼就能看出的地方
区分在两方之间加密的消息和已签名的消息之间的区别很重要。这很重要的一个例子是，如果我可以让收件人回应我发送给他们的声明。用户 A 可以告诉用户 B“A，我欠你 100 美元”。如果 B 用错误的密钥回复了该消息的回声，那么他们有效地以数字方式公证（而不是仅仅加密）虚构的 100 美元债务。
这是S/MIME的示例用户对话框。期待基于浏览器的证书的类似 UI。请注意颁发者名称对用户不友好。
备用编码
注意：说到名称，如果链中的任何链接使用替代编码，则客户端可能无法验证主题的颁发者字段。Windows 在比较期间不会规范化这些字符串，因此请确保 CA 的名称从二进制角度来看是相同的（与 RFC 建议相反）。
高安全性/Suite B 部署
以下是有关 Windows 2008 和 R2 中支持的 Suite B 算法的信息
算法 秘密 绝密
加密：高级标准 (AES) 128 位 256 位
数字签名：椭圆曲线数字签名算法 (ECDSA) 256 位曲线。384位曲线
密钥交换：椭圆曲线 Diffie-Hellman (ECDH) 256 位曲线。384位曲线
散列：安全散列算法 (SHA) SHA-256 SHA-384
对于套件 B 合规性，如果所需的分类级别是最高机密，则ECDSA_P384#Microsoft Software Key Service Provider还可以选择384密钥大小和哈希算法。SHA384应使用与所需分类级别相对应的设置。ECDSA_P521也可作为选项使用。虽然使用 521 位 ECC 曲线可能会超出 Suite B 的加密要求，但由于非标准密钥大小，521 不是官方 Suite B 规范的一部分。
PKCS#1 v2.1
XP 客户端和许多非 Windows 系统不支持这种新的签名格式。 如果需要支持较旧的客户端，则应禁用此功能。更多信息
我只建议在您使用 ECC 算法进行非对称加密时使用它。（来源）
保护 Microsoft CA DCOM 端口
默认情况下，Windows Server 2003 CA 不对 ICertRequest 或 ICertAdmin DCOM 接口强制加密。通常，除非在特殊操作场景中，否则不需要此设置，不应启用此设置。默认情况下，只有 Windows Server 2003 机器支持这些接口上的 DCOM 加密。例如，默认情况下，Windows XP 客户端不会对 Windows Server 2003 CA 的证书请求实施加密。来源
CNG 私钥存储与 CSP 存储
如果您注册证书模板 v3，私钥将进入客户端计算机上的 CNG 私钥存储。如果您注册证书模板 v2 或 v1，私钥将进入 CSP 存储。在这两种情况下，证书对所有应用程序都是可见的，但它们的私钥不可见 - 因此大多数应用程序将显示证书可用，但除非它们支持 CNG 存储，否则将无法使用关联的私钥对数据进行签名或解密。
您无法使用证书 MMC 区分 CNG 和 CSP 存储。如果您想查看特定证书正在使用什么存储，您必须使用CERTUTIL -repairstore my *(或CERTUTIL -user -repairstore my *) 并查看 Provider 字段。如果它说“... Key Storage Provider”，那么它是 CNG 而所有其他提供者都是 CSP。
如果您手动创建初始证书请求（在 MMC 中创建自定义请求），您可以在“CNG 存储”和“旧版密钥”之间进行选择，其中旧版表示 CSP。以下是我根据经验列出的不支持 CNG 的列表 - 你在任何地方都找不到权威列表，所以这是我随着时间的推移进行的调查得出的：
EFS 在 Windows 2008/Vista 中不支持，在 Windows 7/2008R2 中支持
用户加密证书
VPN/WiFi 客户端（EAPTLS、PEAP 客户端）
Windows 2008/7 不支持用户或计算机证书身份验证
Web 侦听器上的 TMG 2010 服务器证书
用于签名或加密的 Outlook 2003 用户电子邮件证书
Kerberos Windows 2008/Vista-DC 证书
系统中心运营经理 2007 R2
系统中心配置管理器 2007 R2
SQL Server 2008 R2-
Forefront Identity Manager 2010 证书管理
此处列出了有关 CNG 兼容性的更多信息（在捷克语中，尽管 Chrome 可以很好地处理自动翻译）
智能卡和发行 CA
如果您计划为用户提供第二张智能卡进行身份验证，请为此使用第二张颁发者 CA。原因：Windows 7 要求
使用 Windows 命令CERTUTIL -viewstore -enterprise NTAuth对智能卡登录进行故障排除。本地 NTAuth 存储是从 Active Directory NTAuth 存储最后一次组策略下载的结果。它是智能卡登录使用的存储，因此在解决智能卡登录故障时查看此存储很有用。
停用 PKI 树
如果您部署两个 PKI 树，并打算在某个时候停用旧树（所有旧设备都已过时或升级），将 CRL Next Update 字段设置为 Null 可能是个好主意。这将（应该？）防止不断向客户端轮询新的 CRLS。理由是，一旦 PKI 退役，将不再有管理，也不再有被撤销的证书。所有剩余的证书都将过期。
AD CS 特定命令
这是与配置 Windows 2008 R2 CA 服务器相关的命令列表。我从另一篇文章中删除了它们，因为该信息太长了，而且并非所有命令都与设置 CA 直接相关。
这更多的是“如何”部分，而不是“什么和为什么”。它还包括 CA 版本之间的特定于版本的差异（2000 与 2003 与 2008）
列出哪些注册策略编辑标志
来自客户端的某些请求可能会根据这些隐藏的服务器设置自动剥离。
C:\Users\ChrisLamont>certutil -getreg
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:
Keys:
Secure Email Root v1
Values:
Active REG_SZ = Secure Email Root v1
DBDirectory REG_SZ = C:\Windows\system32\CertLog
DBLogDirectory REG_SZ = C:\Windows\system32\CertLog
DBTempDirectory REG_SZ = C:\Windows\system32\CertLog
DBSystemDirectory REG_SZ = C:\Windows\system32\CertLog
DBSessionCount REG_DWORD = 64 (100)
LDAPFlags REG_DWORD = 0
DBFlags REG_DWORD = b0 (176)
DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
DBFLAGS_LOGBUFFERSHUGE -- 80 (128)
Version REG_DWORD = 40001 (262145) -- 4.1
SetupStatus REG_DWORD = 6001 (24577)
SETUP_SERVER_FLAG -- 1
SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.
C:\Users\ChrisLamont>certutil -getreg policy\editflags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:
EditFlags REG_DWORD = 83ee (33774)
EDITF_REQUESTEXTENSIONLIST -- 2
EDITF_DISABLEEXTENSIONLIST -- 4
EDITF_ADDOLDKEYUSAGE -- 8 // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement
EDITF_ATTRIBUTEENDDATE -- 20 (32)
EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
EDITF_BASICCONSTRAINTSCA -- 80 (128)
EDITF_ENABLEAKIKEYID -- 100 (256)
EDITF_ATTRIBUTECA -- 200 (512)
EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.
解决方案是运行certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE依次更新的命令
Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:
如何基于每个 CA 定义策略
要在颁发的证书中包含策略，请在命令提示符处输入以下命令：
certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
certutil –shudown
net start certsvc
您可以使用禁用该设置
certutil -v -setreg policy\EnableRequestExtensionlist "-2.5.29.32"
certutil –shudown
net start certsvc
如何定义 OCSP 缓存持续时间
以下命令可让您设置、修改和删除 Max-Age 标头设置。
appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']
查看当前的 httpProtocol 自定义标头
appcmd list config /section:httpProtocol
如何将离线 CA 证书导入 AD
:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
: |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl connoam-ca-00 IntermediateCA1
如何启用 PKCS#1 v1.21
当 CAPolicy.inf 文件具有AlternateSignatureAlgorithm=1. 请务必注意兼容性问题。
最后应该知道，安装 AD 证书服务并不像添加角色那么简单。您应该检查此VBS 安装脚本并确保文件CAPolicy.inf应根据您的环境需要进行编辑
如何定义交叉证书分发点
[CrossCertificateDistributionPointsExtension]Windows AD 证书服务在带有条目的 CAPolicy.info 文件中启用此功能
其他：将 Windows 2000 CA 升级到 Windows 2003 时的 AIA 差异
请注意，Windows 2000 和 2003 CA 之间的行为有所不同。Windows CA 颁发的证书的 AKI 扩展在 Windows 2000 和 Windows Server 2003 之间有所不同。默认情况下，以下信息存储在颁发的证书的 AIA 扩展中。
Windows 2000 CA 颁发的证书的 AIA 扩展包括颁发 CA 的 LDAP DN（颁发者名称）、颁发 CA 证书的序列号和 CA 证书公钥的密钥哈希。
Windows Server 2003 CA 颁发的证书的 AIA 扩展仅包括颁发 CA 的公钥的散列，也称为 Key-ID。
行为的变化是由于更新 CA 证书时可能发生的链接错误。如果用于签署已颁发证书的 CA 证书对客户端不可用，默认的 Windows 2000 行为可能会导致链不完整。对于 Windows Server 2003 默认行为，如果使用相同密钥对更新 CA，则使用相同密钥对的颁发 CA 的任何 CA 证书都可以包含在证书链中。
您可以通过运行此命令来模仿旧行为
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL
在 AD 中列出证书
此命令将列出在 Active Directory 中发布的证书。
certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"
ISIS MTT v1.1 PKI 兼容性
有关程序，请参阅此知识库文章，这里也是ISIS MTT v1.1 的替代 CAPolicy.inf 方法
清单上的一点经常被遗漏：
尤其是 如果您实施 CA。
我之前的答案空间不足，但认为这是有效且有用的信息：
撤销
接下来的几节将讨论 CRL 和证书，但在您走得太远之前，我想提请您注意一个可能影响生产和 PKI 操作的问题：如果您认为您的 PKI 将使用 Microsoft 的 PKI（Active Directory 证书）吊销相同的证书两次服务），那么吊销日期将是第二次吊销的日期，而不是第一次吊销的日期。但是，如果您使用 Microsoft 的 FIM CM 产品（Forefront Identity Management -- Certificate Management）管理智能卡上的证书，那么您将进行此类重复撤销。来源