PKI公钥基础设施

PKI(Public Key Infrastructure)公钥基础设施，是提供公钥加密和数字签名服务的系统或平台，是一个包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。企业通过采用 PKI 框架管理密钥和证书可以建立一个安全的网络环境。
PKI 的基础技术包括:公钥加密、数字签名、数据完整性机制、数字信封(混合加密)、双重数字签名等。
PKI 体系能够实现的功能有:

• 身份验证;
• 数据完整性
• 数据机密性
• 操作的不可否认性

微软的活动目录证书服务 ADCS 就是对 PKI 的实现，活动目录证书服务能够跟现有的活动目录域服务(ADDS:Active Directory Domain Service)进行结合， 可以用于身份验证、公钥加密和数字签名等。ADCS 提供所有与 PKI 相关的组件作为角色服务。每个角色服务负责证书基础架构的特定部分，同时协同工作以形成完整的解决方案。
ADCS 允许你做如下的操作

• 设置 Web 注册、网络设备注册服务和在线响应器服务。
• 管理用户、计算机、服务和路由器等网络设备的证书的注册和吊销。
• 使用组策略来分发和管理证书

CA证书颁发机构

CA(Certificate Authority，证书颁发机构)是 PKI 系统的核心。其作用包括处理证书申请、 证书发放、 证书更新、管理已颁发的证书、吊销证书和发布证书吊销列表(CRL)等。
Active Directory 证书服务中的 CA 有企业 CA 和独立 CA。企业 CA 必须是域成员，并且通常处于联机状态以颁发证书或证书策略。而独立 CA 可以是成员、 工作组或域。独立 CA 不需要 ADDS 活动目录域服务，并且可以在没有网络的情况下使用。但是在域中基本都是使用企业 CA，因为企业 CA 可以和活动目录域服务 ADDS 进行结合，其信息也存储在 Active Directory 数据库中。企业 CA 支持基于证书模块创建证书和自动注册证书。

在创建 CA 后，会自动创建 CA 的公私钥对:

• 私钥只有 CA 知道，私钥用于对颁发的证书进行数字签名。
• 公钥任何人都可以知道，公钥用于验证证书是否由 CA 颁发

然后 CA 使用自己的私钥签署新证书来生成自己的根 CA 证书，也就是说根 CA 证书是自签名的。ADCS 会将根 CA 证书的 Subject 和 Issuer 字段设置为 CA 的名称，将 Basic Constraints 设置为 Subject Type=CA，并将 NotBefore/NotAfter 字段设置为五年(默认情况下)。域内所有主机会将根 CA证书添加到受信任的根证书颁发机构中。此后，该 CA 签名发行的所有证书都会被域内主机所信任。
在我们根 CA 颁发的证书这里可以看到已经颁发的证书，以下证书应用的网站会被域内所有机器信任。

域外机器如何信任域内搭建的根CA颁发的证书呢
只需把域内搭建的根CA证书手动导入到系统中即可
访问ADCS证书服务器的/certsrv/certcarc.asp 路径，点击下载 CA 证书，然后将下载的 CA 证书导入系统“受信任的根证书颁发机构”内，并勾选始终信任

CA层次结构

常见的 CA 层次机构有两个级别，根和二级 CA，二级 CA 也叫子从属 CA。 根 CA 位于顶级，子从属 CA 在第二级。在这种层次机构下，根 CA 给子从属 CA 颁发证书认证，子从属 CA 给下面的应用颁发和管理证书，根 CA 不直接给应用颁发证书。

CA 的层次结构，有以下优点:

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

CRL证书作废列表

CRL (Certificate Revocation List):证书作废列表，就是我们所称的“证书黑名单”，在证书的有效期期间，因为某种原因(如人员调动、私钥泄漏等等)，导致相应的数字证书内容不再是真实可信。此时，进行证书撤销，说明该证书无效，CRL 中列出了被撤销的证书序列号。

证书

证书是 X.509 格式的数字签名文档，用户加密、消息签名或身份验证等功能 。证书通常具有多个字段，包括如下:

• Subject:主题，可以标识证书的所有者
• Public Key:公钥，用于将主题(Subject)与单独存储的私钥相关联
• NotBefore and NotAfter dates:证书的有效期
• Serial Number:CA 分配的证书标识符
• Issuer:标识颁发证书的人(通常是 CA)
• SubjectAlternativeName(SAN):主题备用名称，定义一个或多个可供主题(Subject)使用的可选名称
• Basic Constraints:基本约束，标识证书是 CA 还是最终实体，以及在使用证书时是否存在任何约束
• Extender key Usages(EKU):扩展密钥用法，描述证书将如何使用的对象标识符(OID) 。常见的 EKU OID 如下:
  • 代码签名(OID 1.3.6.1.5.5.7.3.3):证书用于签署可执行代码
  • 加密文件系统(OID 1.3.6.1.4.1.311.10.3.4):证书用于加密文件系统
  • 安全电子邮件(OID 1.3.6.1.5.5.7.3.4):证书用于加密电子邮件
  • 客户端身份验证(OID 1.3.6.1.5.5.7.3.2):证书用于身份验证到另一个服务器
  • 智能卡登录(OID 1.3.6.1.4.1.311.20.2.2):证书用于智能卡认证
  • 服务器认证(OID 1.3.6.1.5.5.7.3.1):证书用于识别服务器 (例如HTTPS 证书)
  • PKINIT 客户端身份验证，对应的 OID 为 1.3.6.1.5.2.3.4
  • 任何目的，对应的 OID 为 2.5.29.37.0
• Signature Algorithm:签名算法，指定用于签署证书的算法
• Signature:使用颁发者的私钥对证书进行签名

PKINIT Kerberos认证

ADCS 服务可以和 ADDS 紧密搭配使用，那么自然利用证书来进行 Kerberos 预身份认证
申请新证书

导出该证书，选择和私钥一起导出

设置密码为root

导出成功

使用 Rubeus 执行如下命令用证书 administrator.pfx 进行 Kerberos 认证

Rubeus.exe asktgt /user:Administrator /password:root /certificate:administrator.pfx /domain:tmac.com /dc:WIN-3EAQBB8A70H.tmac.com

在微软的官方文档中有这么一句话:为了支持连接到不支持 Kerberos 身份验证的网络服务的应用程序的 NTLM 身份验证，当使用 PKCA 时， KDC 将在 PAC 特权属性证书的 PAC_CREDENTIAL_INFO 缓冲区中返回用户的 NTLM Hash。也就是说当使用证书进行 Kerberos 认证时，返回的票据的 PAC 中是包含用户的 NTLM Hash 的
使用 kekeo 执行如下命令获得 administrator.pfx 证书对应的 administrator 用户的 NTLM Hash

tgt::pac /subject:administrator /castore:current_user /domain:tmac.com /user:administrator /cred

后续无论用户密码怎么更改，使用该功能获取用户的 NTLM Hash 都是最新的
在使用 kekeo 获取证书对应用户的 NTLM Hash 时，需要先将证书导入 到系统中。
能用于 Kerberos 认证的模版证书

• 客户端身份验证，对应的 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

活动目录数据库中的ADCS

安装完 ADCS 证书服务后，可以在活动目录数据库中找到相关数据，完整路径为:CN=Public Key Services,CN=Services,CN=Configuration,DC=tmac,DC=com

Certification Authorities

Certification Authorities 是 CA 认证机构类，里面的实例都是受信任的CA，AD将这些CA的证书下发到每台 Windows 计算机的受信任的根证书颁发机构证书存储区。为了使 AD 认为证书是可信的，证书的信任链最终必须以该容器中定义的根 CA 之一结束。

CA 证书类的 objectClass 属性为 certificationAuthority，cACertificate 属性为 CA 证书的二进制内容

Certificate Templates

Certification Authorities 是证书模板类，里面的实例都是证书模板

证书模板的 objectClass 属性为 pKICertificateTemplate

Enrollment Services

Enrollment Services 是企业 CA 类，里面的实例都是企业 CA

企业 CA 的 objectClass 属性为 pKIEnrollmentService、dNSHostName 属性是企业 CA 的主机名、cACertificate 属性值包含 CA 证书的二进制内容、 certificateTemplates 字段定义了启用的证书模板。证书模板是 CA 在创建证书时 使用的设置 “蓝图”，包括 EKU、注册权限、证书到期、颁发要求和加密设置等内容。

NTAuthCertificates

该容器定义了有资格颁发身份验证证书的 CA 证书。这个对象的 objectClass 属性值为 certificateAuthority，并且 cACertificate 属性定义了一个 可信 CA 证书的二进制数组。加入 AD 的 Windows 机器将这些 CA 证书下发到每 台机器上的中间证书颁发机构证书存储区。仅当 NTAuthCertificates 对象定义的 CA 签署了身份验证客户端的证书时，客户端应用程序才能使用证书向 AD 进行身份验证。

AIA（Authority Information Access）

该容器保存了中间 CA 证书的 AD 对象。中间 CA 是 PKI 树层次结构中根 CA 的 “子代”，因此，此容器的存在是为了帮助验证证书链。与 Certification Authorities 容器一样，每个 CA 在 AIA 容器中表示为一个 AD 对象，其中 objectClass 属性设置为 CertificationAuthority，并且 cACertificate 属性包含 CA 证书的二进制内容。当有新的 CA 安装时，它的证书则会自动放到 AIA 容器 中。这些 CAs 传播到每台机器上的中间证书颁发机构证书存储区。

不同后缀的证书文件

我们经常会看到不同后缀格式的证书，如下是不同后缀格式证书包含的内容：

• pfx、.p12、.pkcs12 后缀:包含证书和私钥，最有用。会有密码保护，导出该类型证书时会要求你输入一个密码
• .pem 后缀:含有证书和私钥
• .cer/.crt 后缀:包含证书
• .key后缀:只包含私钥
• .csr 后缀:证书申请文件，既不包含公钥也不包含私钥
• jks/.keystore/.keys:Java 密钥库，可能包含 Java 应用程序使用 的 certs +私钥

.pfx 格式的文件 可以转化成.pem 格式的文件
.pem 格式的文件中可以转化成.cer 证书文件 + .key 私钥

导出pfx证书文件

导出

勾选将私钥和证书一起导出

这里需要输入一个密码，我们输入的是root

从.pfx文件中提取出包含私钥和证书的.pem文件

openssl pkcs12 -in administrator.pfx -nodes -out administrator.pem

从.pem文件中提取出.cer证书文件

openssl x509 -in administrator.pem -out administrator.cer

定位证书服务器

域内

在域内的话，可以执行如下命令定位证书服务器

certutil.exe
#弹框
certutil -config - -ping

域外

在域外的话，可以利用certipy工具执行命令定位证书服务器
certipy安装方法

pip3 install certipy-ad

certipy find -u administrator@xie.com -p admin@123 -dc-ip 192.168.1.11 -dc-only