记一次滚动内网 Root CA 及 ADCS Issuing CA

Jun 28, 2023 · 1767 words · 9 minute read

Sysadmin Windows PKI

是这样，我在 2022 年 4 月份给内网配了 PKI，是二级架构且有公网可达 CDP 及 AIA。但由于当时不懂 PKI，所以盲目参考了一些教程。配出来的东西虽然可用，但也只是勉勉强强，有很多问题。

之前的配置 #

根证书：ADCS 2022，离线，但是是在我日用电脑的加密 VMware 虚拟机中生成的。

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            50:ee:42:59:f1:61:06:89:43:aa:79:c0:15:ee:b5:33
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: CN = ROOTCA
        Validity
            Not Before: Apr  4 19:46:00 2022 GMT
            Not After : Apr  4 19:55:59 2042 GMT
        Subject: CN = ROOTCA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus: ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                0F:5A:DB:23:C4:4F:02:05:F9:B5:E1:E5:A7:F3:44:46:BB:2E:F6:B3
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://home.yuuta.moe/cdp/RootCA.crl
            1.3.6.1.4.1.311.21.1: 
                ...
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.114514.5.1.1
                  User Notice:
                    Explicit Text: 
                  CPS: https://home.yuuta.moe/cps
                Policy: 1.3.6.1.4.1.114514.5.1.2
                  User Notice:
                    Explicit Text: 
                  CPS: https://home.yuuta.moe/cps
                Policy: 1.3.6.1.4.1.114514.5.1.3
                  User Notice:
                    Explicit Text: 
                  CPS: https://home.yuuta.moe/cps
            Authority Information Access: 
                CA Issuers - URI:http://home.yuuta.moe/Public/RootCA.crt

这个证书有如下问题：

非常不安全：虽然是在断网的 VM 中生成的，但其虚拟磁盘文件通过弱密码保存在平时上网用的电脑中。访问该 VM 时没有任何隔离保护。
Subject 瞎写：我写了个 CN=ROOTCA，非常不好看。
有 CPS 但 Private OID 填的 114514。
CPS 链接 404。
CRL 之前一直签署的时间不够长，导致经常过期，且没有自动化的方式及时更新，导致域中很多需要检查证书链 CRL 的地方都工作异常。
根证书完全不需要带 CDP 和 AIA。这些 Extension 都指向 Issuer，因此在根证书上写自己的 CDP 和 AIA 完全没有意义。
根据 CA Browser Forum（下文简称 CAB）的规定，Subject 必须带有至少 C= （国家名）。

以及，二级证书联网用于自动签发。采用加域的 ADCS 2022 做的 Enterprise Subordinate CA，以下简称 Issuing CA：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            24:00:00:00:02:3c:f7:67:5d:7a:ff:fe:50:00:00:00:00:00:02
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: CN = ROOTCA
        Validity
            Not Before: Apr  4 22:06:05 2022 GMT
            Not After : Apr  4 22:16:05 2032 GMT
        Subject: DC = MOE, DC = YUUTA, DC = AD, CN = Yuuta Home Issuing CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus: ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.21.1: 
                ...
            X509v3 Subject Key Identifier: 
                B1:C2:A7:81:63:66:4B:72:0A:DD:FD:7D:20:29:BD:6B:49:09:61:C0
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.114514.5.1.2
                  User Notice:
                    Explicit Text: 
                  CPS: https://home.yuuta.moe/cps
            1.3.6.1.4.1.311.20.2: 
                .
.S.u.b.C.A
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier: 
                0F:5A:DB:23:C4:4F:02:05:F9:B5:E1:E5:A7:F3:44:46:BB:2E:F6:B3
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://home.yuuta.moe/ROOTCA.crl
            Authority Information Access: 
                CA Issuers - URI:http://home.yuuta.moe/ROOTCA_ROOTCA.crt
    Signature Algorithm: sha512WithRSAEncryption

由它签发的客户端证书（以下简称 Leaf Cert）比如：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            44:00:00:00:1f:87:23:53:ce:f3:7e:e6:64:00:00:00:00:00:1f
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: DC = MOE, DC = YUUTA, DC = AD, CN = Yuuta Home Issuing CA
        Validity
            Not Before: May 14 05:45:17 2023 GMT
            Not After : May 13 05:45:17 2024 GMT
        Subject: DC = MOE, DC = YUUTA, DC = AD, OU = Domain Users, CN = Yuuta Liang
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus: ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.21.7: 
                0..&+.....7....c...J...0...g...T.....A...Q..d...
            X509v3 Extended Key Usage: 
                Microsoft Smartcard Login, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            1.3.6.1.4.1.311.21.10: 
                0.0..
+.....7...0
..+.......
            S/MIME Capabilities: 
                0..0...`.H.e...*0...`.H.e...-0...`.H.e....0...`.H.e....0...`.H.e....0...`.H.e....0
......0...*.H..*.H..
            X509v3 Subject Alternative Name: 
                othername: UPN::yuuta@yuuta.moe
            X509v3 Subject Key Identifier: 
                74:22:2E:C0:4D:5A:65:54:8C:06:80:4C:80:21:76:73:13:EF:F2:A9
            X509v3 Authority Key Identifier: 
                B1:C2:A7:81:63:66:4B:72:0A:DD:FD:7D:20:29:BD:6B:49:09:61:C0
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:ldap:///CN=Yuuta%20Home%20Issuing%20CA,CN=CA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=AD,DC=YUUTA,DC=MOE?certificateRevocationList?base?objectClass=cRLDistributionPoint
                  URI:http://home.yuuta.moe/Yuuta%20Home%20Issuing%20CA.crl
            Authority Information Access: 
                CA Issuers - URI:http://home.yuuta.moe/CA.AD.YUUTA.MOE_Yuuta%20Home%20Issuing%20CA.crt
                CA Issuers - URI:ldap:///CN=Yuuta%20Home%20Issuing%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=AD,DC=YUUTA,DC=MOE?cACertificate?base?objectClass=certificationAuthority
            1.3.6.1.4.1.311.25.2: 
                0@.>.
+.....7....0..S-1-5-21-2974468247-3350989149-1512396042-1108
    Signature Algorithm: sha512WithRSAEncryption

它有如下问题：

虽然填写了公网可达的 CRL，但并没有自动更新，导致日常过期。
Leaf Cert 的 CDP 和 AIA 配置混乱且复杂：照抄了网上的配置，写了 LDAP，导致容易 Offline。
Delta CRL 配置混乱。
ADCS Template 配置混乱。

为了解决这些问题，我认真学习了一下 PKI 和 X.509。于是在本月对 PKI 进行了翻新。在这里简单记录以下翻新过程。

非常感谢 Jimmy Xu，在整个过程中提供了很多关于 ADCS、AD、OpenSSL、PKI 的帮助，以及帮我查阅了很多 RFC。

同时感谢群友 hanyuwei 及 James Swineson 的帮助。

新根证书 #

配置：

安全：使用 OpenSSL 在 Air Gapped 电脑上生成，并保存至 HSM（穷人选择了 YubiKey PIV）。签名时使用 HSM，只有紧急情况才使用加密的密钥备份。YubiKey PIN 手抄至信封。理论上签名操作也应该在 Air Gapped 电脑上完成，但我偷懒了 qwq
规范：尽可能使用 CAB 规范中对根证书允许的配置，诸如 X.509v3 拓展、Subject、算法等。

参考 CAB Baseline Requirements： https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.0.pdf

因此，最后的配置梗概如下：

Subject: CN = Yuuta Root CA, C = CA （CAB 要求必须有 CN 和 C，其他可选）
有效期：25 年（根据 CAB 规定）
算法：ECC P-256（CAB 仅允许 RSA >= 2048 或 ECC >= P-256，因为 ECC 密钥和签名都短一些，就选了 ECC）
X.509 拓展：Subject Key Identifier、Authority Key Identifier（根据 CAB 规定），以及 Basic Constraints CA 及 Key Usage Digital Signature、 Certificate Sign、 CRL Sign。没有 CDP 及 AIA，没有 CPS，没有 EKU。
CRL：无 Delta CRL。有效期为一年。
证书管理、生成、签发：OpenSSL + YubiKey PIV 9c；明文密钥通过 GPG 加密进行备份。

最终完整证书：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            70:fa:0f:fa:a6:d7:f4:b4:93:05:5d:a9:d3:e4:42:a8:52:60:b3:f8
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = Yuuta Root CA, C = CA
        Validity
            Not Before: Jun 23 02:50:46 2023 GMT
            Not After : Jun 23 02:50:46 2048 GMT
        Subject: CN = Yuuta Root CA, C = CA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:1d:e8:71:bc:dd:48:70:26:71:6c:dd:04:5b:3f:
                    5d:de:14:31:8b:3f:31:80:18:2a:33:e5:19:86:13:
                    d6:e7:48:2f:95:15:3a:59:8d:ed:09:e4:53:1a:f3:
                    61:b2:35:61:6e:66:5f:5f:cf:0a:e2:65:65:3d:22:
                    2b:30:71:2c:24
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                78:92:E0:6C:70:F5:A3:BE:02:EE:44:BA:A7:8C:DA:D6:B5:43:A7:93
            X509v3 Authority Key Identifier: 
                78:92:E0:6C:70:F5:A3:BE:02:EE:44:BA:A7:8C:DA:D6:B5:43:A7:93
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:20:09:af:a4:ba:c6:48:31:32:2b:45:9a:74:bf:d1:
        c2:2e:13:b5:bd:62:48:a2:e5:dd:85:7b:df:8b:bb:89:cb:f7:
        02:21:00:8c:07:9c:0b:d9:e1:8c:f0:7d:8e:8f:e4:ae:12:68:
        1c:33:cc:a3:e2:ab:6c:dd:a5:a5:c1:9b:49:57:a9:cb:33

具体如何使用 OpenSSL 生成一个证书的配置详见： https://git.yuuta.moe/ca.git/tree/?id=3a778dc82e54605326cdf26a29b57e4c496603f3 以及 README 中的 Acknowledgment。

具体如何让 OpenSSL 使用 YubiKey 详见： https://git.yuuta.moe/ca.git/commit/?id=35deca68d108a51054780943c20e2d597ffbc17d

注，其中的 URL 通过 p11tool --provider /usr/lib/opensc-pkcs11.so --list-privkeys --login 获得，参考 https://support.nitrokey.com/t/pki-ca-nitrokey-hsm-does-not-support-signing/2598/6 。

关于新 Issuing CA 证书的配置自然是在 Root CA 中进行的，具体配置写在 OpenSSl 配置文件中。重要配置项如下：

Subject：保持和老 Issuing CA 完全一致（见下节）。
有效期：十年。
X.509 拓展：Subject Key Identifier、Authority Key Identifier、Basic Constraints CA + pathlen = 0、Key Usage Digital Signature、Certificate Sign、CRL Sign。
CDP 为 HTTP 的 Root CA CRL，格式必须为 DER （见 RFC 规定： https://datatracker.ietf.org/doc/html/rfc5280#page-46 ）。
AIA 为 HTTP 的 Root CA 证书。

供参考：签发的 CRL 为：

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: CN = Yuuta Root CA, C = CA
        Last Update: Jun 24 00:21:30 2023 GMT
        Next Update: Jun 23 00:21:30 2024 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                78:92:E0:6C:70:F5:A3:BE:02:EE:44:BA:A7:8C:DA:D6:B5:43:A7:93
            X509v3 CRL Number: 
                1
Revoked Certificates:
    Serial Number: 24E4F8697670EFB0AE09F35FAB8D438AF474865F
        Revocation Date: Jun 24 00:21:15 2023 GMT
    Signature Algorithm: ecdsa-with-SHA512
    Signature Value:
        30:45:02:21:00:83:1f:55:17:2e:c4:fb:dd:49:e6:f0:02:70:
        33:e2:96:66:b5:a4:88:c7:94:c6:44:c0:ee:13:d2:21:11:5a:
        0d:02:20:44:b4:d2:b3:1e:83:6e:ac:06:4b:01:3b:82:fc:39:
        22:12:ff:45:06:a0:b8:38:28:01:97:a7:a2:a3:7b:8e:d3

新 Issuing CA #

为了避免维护困难，我直接使用新根证书续签了 Issuing CA。根据 PKI 认证流程，只要 CA 的 Subject 及 Public Key 不变，那么就将视作同一个 CA。因此可以直接使用不同的 Issuer 续签 Issuing CA，只要保证不改变密钥和 Subject 即可。

整个过程非常简单，只需 certutil -renewCert ReuseKeys 并 certutil -installCert 即可。参见： https://learn.microsoft.com/en-us/windows/win32/seccrypto/certification-authority-renewal 。

打开 Certification Authority MMC，右键 CA 服务器，点击属性，应该可以看到新的 CA 证书被加了 (1)。

最终签发的新证书为：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3e:10:93:9d:e4:57:8d:39:87:fd:ff:42:7b:da:65:5b:1f:21:cb:07
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: CN = Yuuta Root CA, C = CA
        Validity
            Not Before: Jun 24 00:15:22 2023 GMT
            Not After : Jun 21 00:15:22 2033 GMT
        Subject: DC = MOE, DC = YUUTA, DC = AD, CN = Yuuta Home Issuing CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus: ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                B1:C2:A7:81:63:66:4B:72:0A:DD:FD:7D:20:29:BD:6B:49:09:61:C0
            X509v3 Authority Key Identifier: 
                78:92:E0:6C:70:F5:A3:BE:02:EE:44:BA:A7:8C:DA:D6:B5:43:A7:93
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://home.yuuta.moe/pki/rootca.crl
            Authority Information Access: 
                CA Issuers - URI:http://home.yuuta.moe/pki/rootca.crt
    Signature Algorithm: ecdsa-with-SHA512
    Signature Value:
        30:44:02:20:74:a1:a7:b4:b0:6d:0d:ab:40:2e:e5:f2:ee:2e:
        f6:b4:94:e9:99:78:0d:17:f2:a2:be:23:88:71:80:8e:6d:20:
        02:20:1b:38:79:3a:ab:ed:d5:9b:7b:aa:26:3f:76:a3:5c:83:
        97:4f:69:14:d2:2b:ca:88:c7:30:34:41:a4:79:7a:c9

参考： https://blog.swineson.me/zh/active-directory-certificate-services-basic-config/

CRL 及 Delta CRL 配置 #

为了避免 LDAP 导致不必要的麻烦，之后签发的 Leaf Cert 的 CDP 及 AIA 都不会带有 LDAP URL。为了保证兼容性，ADCS 会继续向 LDAP 发布 CRL 及证书，但不会包含在 X.509 拓展中。

同时，也对 CDP 及 AIA 的 HTTP URL 进行了规范。

以下是包含在 Issuing CA 签发的 Leaf Cert 拓展中的信息：

CDP：http://home.yuuta.moe/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl，同时也包含在签发的 Base CRL 的 Freshest CRL 拓展中。 Freshest CRL（RFC： https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.6 ）用来指定 Delta CRL 的 URL。在我的配置中，ADCS 会自动在 Base CRL 的 Freshest CRL 拓展中加入 +.crl 文件名，这应该是 <DeltaCRLAllowed> 的结果。
AIA：http://home.yuuta.moe/pki/<CaName><CertificateName>.crt

ADCS 自然不可能自动给 Web Server 提交文件，因此我们配置 ADCS 向如下位置发布 CRL 及 AIA：

CRL:
- ldap://CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass> ：（这应该是默认配置？）向 AD 的 Configuration tree 中的 PKI 中写入，其重要性及原理见下文。
- C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl：写入到文件，方便复制进 Web Server
AIA：
- ldap://CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass> ：这应该是默认配置？同理。
- 文件系统发布自行设置，我这里使用了 <CaName><CertificateName>。

注意以下几点：

ADCS 的 CRL 签发是 per-CA 而不是 per-Cert 的。即，如果 ADCS 更换证书但不更换密钥，则它只会继续签发同一份 CRL，不会单独给老 Cert 签发一份。
ADCS 在更换证书后会保留原证书，并会给新的证书加 (1)，且这个名字会作用于 AIA 的 <CertificateName> 中。这非常难看，但 ADCS 就是这样设计的。因此，在分发 AIA 时，记得同时保留老证书及新证书，新证书加 (1)。
记得保留 <DeltaCRLAllowed>，它就是 Delta CRL 文件名中的那个 +。否则似乎发布 CRL 到文件系统时 Delta CRL 会直接覆盖掉 Base CRL（？）；同时记得保留 <CRLNameSuffix>，因为我也不知道它是干嘛的（

之后可以使用 certutil -CRL 来测试 Publish，每次 Publish 时 ADCS 会自动增加 CRL Number。可以通过右键 Certification Authority > Revoked Certs > 属性 > View CRLs 来查看最新 CRL，这里看到的 CRL 一定是最新的，而文件系统中发布的 CRL 可能会因为各种配置错误导致有问题，可以以此进行对比。

参考：

一切就绪后，签发的 Leaf Cert 如下：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            44:00:00:00:34:d6:36:59:38:b4:da:c4:41:00:01:00:00:00:34
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: DC = MOE, DC = YUUTA, DC = AD, CN = Yuuta Home Issuing CA
        Validity
            Not Before: Jun 26 17:26:17 2023 GMT
            Not After : Jun 25 17:26:17 2025 GMT
        Subject: CN = CA.AD.YUUTA.MOE
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus: ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.20.2: 
                ...W.e.b.S.e.r.v.e.r
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Subject Key Identifier: 
                E9:59:69:B0:5B:85:75:87:7C:6E:92:F4:D6:53:22:B8:36:AF:69:34
            X509v3 Subject Alternative Name: 
                DNS:CA.AD.YUUTA.MOE, DNS:CA
            X509v3 Authority Key Identifier: 
                B1:C2:A7:81:63:66:4B:72:0A:DD:FD:7D:20:29:BD:6B:49:09:61:C0
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://home.yuuta.moe/pki/Yuuta%20Home%20Issuing%20CA.crl
            Authority Information Access: 
                CA Issuers - URI:http://home.yuuta.moe/pki/Yuuta%20Home%20Issuing%20CA(1).crt

签发的 Base CRL 为：

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: DC = MOE, DC = YUUTA, DC = AD, CN = Yuuta Home Issuing CA
        Last Update: Jun 26 17:23:59 2023 GMT
        Next Update: Jul 11 05:43:59 2023 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                B1:C2:A7:81:63:66:4B:72:0A:DD:FD:7D:20:29:BD:6B:49:09:61:C0
            1.3.6.1.4.1.311.21.1: 
                ...
            X509v3 CRL Number: 
                300
            1.3.6.1.4.1.311.21.4: 
230710173359Z   .
            X509v3 Freshest CRL: 
                Full Name:
                  URI:http://home.yuuta.moe/pki/Yuuta%20Home%20Issuing%20CA+.crl
Revoked Certificates:

签发的 Delta CRL 为（注意，Delta CRL 带有 Delta CRL Indicator 拓展）：

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: DC = MOE, DC = YUUTA, DC = AD, CN = Yuuta Home Issuing CA
        Last Update: Jun 26 17:23:59 2023 GMT
        Next Update: Jun 28 05:43:59 2023 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                B1:C2:A7:81:63:66:4B:72:0A:DD:FD:7D:20:29:BD:6B:49:09:61:C0
            1.3.6.1.4.1.311.21.1: 
                ...
            X509v3 CRL Number: 
                300
            1.3.6.1.4.1.311.21.4: 
230627173359Z   .
            X509v3 Delta CRL Indicator: critical
                297

注意，请自行使用 certutil -URL 测试 CRL 及 AIA 是否可达。因为 CDP 及 AIA 发生变化，记得同时测试老 Chain 及新 Chain。

同时请使用 PKI View MMC 来检查整个 PKI 是否健康。

最终配置完后请自行配置 ADCS CRL 到 Web 的发布，思路包括但不限于任务计划跑脚本里面跑 scp(1) 或者在 ADCS 上开 IIS，不赘述。

AD 配置 #

最后讲一下 Windows 如何通过 AD 获取证书。根据我的理解，在 gpupdate 时，Windows 客户端会读取 CN = AIA,CN = Public Key Services,CN = Services,CN = Configuration 中的证书，并加入本地 Local Machine -> Intermediate Certificate Authorities Store （如果本地没有）。这里应该是不会删除本地多出来的证书的。

可以通过 ADSI Edit 或 sysinternals AD Explorer 来查看这些 LDAP 容器。

因此，在更新完 Issuing CA 证书并 Publish AIA 后（理论上应该会自动做这个？），客户端只需要运行 gpupdate 即可获得新的 Issuing CA。

Windows 在获得新（续签后的）Issuing CA 后，本地的 Leaf Cert 会自动识别新 Issuing CA，可通过 certlm.mmc 查看证书链。

根据个人理解，整个 ADCS 的 Template、AIA、CDP 以及 ADCS 服务器位置都是通过这个 LDAP 容器分发的，感兴趣的读者可以通过上述两个工具来浏览该容器的内容，并结合 Microsoft 发布的 AD Schema 来理解其中含义。

参考： https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/decommission-enterprise-certification-authority-and-remove-objects

备注：不要过早地 Revoke 老 Issuing CA #

最后说一下遇到的其中一个坑：我太急了，直接早早地在老 Root CA 上把老 Issuing CA 给 Revoke 了，还加进了 CRL，CRL 还签了十年。结果就遇到了下面这堆问题：

Windows Hello for Business 可以登录但拿不到 Kerberos Ticket，Event log 报错：

Security-Kerberos 9: The client has failed to validate the domain controller certificate for <DC> The following error was returned from the certificate validation process: The revocation function was unable to check revocation because the revocation server was offline.

Security-Kerberos 11: The Distinguished Name in the subject field of your smart card logon certificate does not contain enough information to identify the appropriate domain on an non-domain joined computer. Contact your system administrator.

以及，curl(1) 内网 HTTPS 服务器报：

schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

整个问题十分迷惑，因为新的 Issuing CA 和 Root CA 已经通过 LDAP（见上节）分发到了域内所有机器的 Intermediate CA Store 中，且已经确认 Windows 已经识别了新的 Chain。同时确认了 TLS 服务端发来的证书链确实在使用新的证书，以及 openssl-verify(1) 和 certutil -URL 验证都完全通过。同时，让 TLS 服务器重新续签证书也无济于事。

这里的答案或许是，curl(1) 和上面的 WHfB 域登录都在使用一些和 schannel 有关的组件，而 certutil -URl 或许没有（我不懂 Win32 开发）。而 schannel 或许鬼迷心窍地使用了 Intermediate CA Store 中的老 Issuing CA 来验证，随后发现已经被 Revoke 了，因此报错。

我不知道这个猜想是否正确，但可以证明的是：新 PKI CRL 体系没有问题，以及删掉老证书并重启一两次之后问题消失，最后把证书加回来再重启一两次问题又回来了。

我其实不敢确定这是否和 Revoke 老 Issuing CA 有关，但 whatever 它或许是有影响的？总之，我推了一个 PowerShell 脚本，让机器删掉该证书：

$path = "Cert:\LocalMachine\CA\EA7F8F4D2CCA367B8BB9A26F61EF4F1A97456E5A"
if (Test-Path $path) {
    Remove-Item $path
}