ADCS证书服务

应用场景

上一章详细说明了证书链和证书校验的细节，那么在域内如果让域用户使用证书访问域内服务？

根 ADCS 服务器（根CA）
子 ADCS 服务器（中间CA）
web 服务
域用户

如果采用 根CA证书------中间CA证书------服务器证书 这种证书链来进行通信，我们需要进行如下操作：

子 ADCS 服务器向根 ADCS 服务器申请一个信任证书，暂且称其为 中间 CA 证书。子 ADCS 服务器是中间 CA，它从上级 CA 申请中间 CA 证书。
域内的 Web 服务器向子ADCS 申请 SSL/TLS 服务器证书，用于加密 HTTPS 通信。

注：域用户在根 ADCS 服务器搭建的时候，就已经将根 ADCS 服务器的信任证书存放在本地的 受信任的根证书颁发机构 列表中了，称其为 根 CA 证书 。

当域用户使用 HTTPS 访问 web 服务器时，证书的校验流程如下：

域用户向 web 服务器发送访问请求。
web 服务器将证书链发送给域用户，证书链的层级如下：
- Web 服务器证书：服务器的 SSL/TLS 证书。
- 中间 CA 证书：就是子 ADCS 服务器向根 ADCS 服务器申请的 中间 CA 信任证书 。
- 证书链 包括 Web 服务器证书 和 中间 CA 证书，而 根 CA 证书 存储在客户端的受信任根证书列表中，不在证书链中发送。但是根 CA 证书 是证书校验的证书链的顶端，客户端接收到不携带 根 CA 证书 的证书链后，会在本地寻找 根 CA 证书。
随后域用户进行证书校验，流程如下：
- 使用 根 CA 证书 携带的公钥验证 中间 CA 信任证书 的合法性，验证其合法后进行下一步。
- 使用 中间 CA 信任证书 携带的公钥验证 Web 服务器证书 的合法性，验证其合法后进行下一步。
最后客户端验证了服务端的身份并和服务端使用 Web 服务器证书 的密钥对进行非对称加密通信。

以上这个模型就是当前大多数网站进行 https 通信的模型，中间 CA 会向根 CA 申请 根 CA 证书 的签名，然后网站向中间 CA 申请 中间 CA 证书 的签名，这种 CA 的层次结构，有以下优点：

管理层次分明，便于集中管理、政策制订和实施。
提高 CA 中心的总体性能、减少瓶颈。
有充分的灵活性和可扩展性。
有利于保证 CA 中心的证书验证效率。

但是在一个小型的域环境下，我们可以直接使用 1 个 ADCS 服务器作为根 ADCS 服务器，这样的证书链就只包含 Web 服务器证书 和 域用户本地的根 CA 证书 了。

CRL 证书吊销列表

众所周知，证书链中，如果 根 CA 证书 或 中间 CA 信任证书 的私钥泄露，那么分别导致如下后果：

攻击者可以使用 根 CA 证书 的私钥去伪造 中间 CA 信任证书 的签名或 Web 服务器证书 的签名，以达到伪造 中间 CA 信任证书 或 Web 服务器证书 的目的。
攻击者可以使用 中间 CA 信任证书 的私钥去伪造 Web 服务器证书 的签名，以达到伪造 Web 服务器证书 的目的。
伪造了 Web 服务器证书 就可以和客户端进行 HTTPS 通信，且浏览器承认其合法。

所以证书的私钥是绝对不能泄露的。

证书吊销列表是尚未到期就被证书颁发机构吊销的数字证书的名单。这些在证书吊销列表中的证书不再会受到信任。

PKINIT kerberos 认证

客户端可以使用证书来进行 kerberos 进行身份验证，首先客户端向 根 CA 或 中间 CA 申请一个代表自己身份的证书，身份验证和正常的kerberos 身份验证区别如下：

as-req：客户端将证书发送给 kdc，同时使用私钥对证书进行签名，放在 pA-PK-AS-REQ 字段 。
as-rep：kdc 接受到证书后，进行如下操作：
- 先用证书内公钥对证书签名进行验证，查看其是否合法。
- 如果合法，一步步验证证书链是否合法。
- 如果签名和证书链都合法，那就返回 tgt 认购权证。
- as-rep 中包含被 krbtgt 哈希加密的 tgt（这一点和正常 kerberos 一样），还有证书公钥加密的 Logon Session key
tgs-req：客户端接受到 as-rep 后，使用证书私钥解密获得解密后的 Logon Session key（正常 kerberos 认证流程是通过用户 hash解密的）

as-rep 中包含被 krbtgt 哈希加密的 tgt，还有证书公钥加密的 Logon Session key，往后的流程和正常的 kerberos 认证流程差不多。

注：为了支持连接到不支持 Kerberos 身份验证的网络服务的应用程序的 NTLM 身份验证，当使用 PKCA 时，KDC 将在 PAC 特权属性证书的 PAC_CREDENTIAL_INFO 缓冲区中返回用户的 NTLM Hash。上面这句话是微软官方写的，这样的结果就是，使用证书进行 kerberos 认证时，kdc 返回的 tgt 和 st 中的 pac 信息会携带用户的 NTLM Hash。

安装 adcs 证书服务后，将当前服务器提升为域内的根 CA，为域用户颁发证书，根 CA 证书则存放在域内每台机器的“受信任的根证书颁发机构”中。

存在以下扩展密钥用法（EKU）的证书能进行 kerbeos 认证：

客户端身份验证，对应的 OID 为 1.3.6.1.5.5.7.3.2
PKINIT 客户端身份验证，对应的 OID 为 1.3.6.1.5.2.3.4
智能卡登录，对应的 OID 为 1.3.6.1.4.1.311.20.2.2
任何目的，对应的 OID 为 2.5.29.37.0
子 CA

查看证书

certmgr.msc：查看系统中的证书

certsrv.msc：查看 CA 相关证书

certtmpl.msc：查看证书模板

certutil 命令行

# 查看用户证书
certutil -user -store My
# 查看机器证书
certutil -store My

导出 pfx 证书文件

选中证书，导出

从 pfx 证书文件中导出 server.pem 文件，该 pem 文件包含私钥和证书。
openssl pkcs12 -in administrator.pfx -nodes -out administrator.pem

从.pem 文件中提取出.cer 证书文件
openssl x509 -in administrator.pem -out administrator.cer

定位证书服务器

域内

在域内的话，可以执行如下命令定位证书服务器。
certutil -config - -ping
#或者下面的命令，不弹框定位
certutil -dump -v

域外

在域外的话，可以利用 certipy 工具执行如下命令定位证书服务器。
certipy find -u deandean@HACK.com -p p-0p-0p-0 -dc-ip 192.168.72.21 -debug

此外 certipy 工具将一些模板信息写入到了 txt 文件中。

json 文件中则存放 adcs 服务器相关信息。