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