CA認(rèn)證的流程和原理

1、CA認(rèn)證的流程和原理AD CS(活動(dòng)目錄證書(shū)服務(wù))是微軟的公鑰基礎(chǔ)結(jié)構(gòu)（PKI）的實(shí)現(xiàn)。PKI處理頒發(fā)并管理用于加密和身份驗(yàn)證的的數(shù)字證書(shū)的組件及過(guò)程。 AD CS頒發(fā)的數(shù)字證書(shū)可以用于加密文件系統(tǒng)、電子郵件加密、安全套接字層SSL和身份驗(yàn)證。 安裝了AD CS的服務(wù)器成為證書(shū)頒發(fā)機(jī)構(gòu)CA。1. 數(shù)字證書(shū)數(shù)字證書(shū)是一種電子憑據(jù)用于驗(yàn)證個(gè)人，組織和計(jì)算機(jī)。證書(shū)頒發(fā)機(jī)構(gòu)頒發(fā)和認(rèn)證證書(shū)。數(shù)字證書(shū)提供了一種方法來(lái)驗(yàn)證證書(shū)持有者的身份。證書(shū)使用加密技術(shù)來(lái)解決兩個(gè)實(shí)體之間的問(wèn)題。數(shù)字證書(shū)都用于非對(duì)稱加密，它需要兩個(gè)密鑰，第一個(gè)密鑰是私鑰，它由被頒發(fā)了數(shù)字證書(shū)的用戶或計(jì)算機(jī)安全地存儲(chǔ)，第二個(gè)密鑰是分發(fā)到其它

2、用戶和計(jì)算機(jī)的公鑰。由一個(gè)密鑰加密的數(shù)據(jù)只能由另一個(gè)密鑰解密。這種關(guān)系確保對(duì)加密數(shù)據(jù)的保護(hù)。一張證書(shū)包含下面的數(shù)據(jù)：1.       公用密鑰證書(shū)主題的公鑰和私鑰對(duì)。這樣可以使用證書(shū)來(lái)驗(yàn)證擁有私鑰的個(gè)人或計(jì)算機(jī)的標(biāo)識(shí)。例如，一臺(tái)web服務(wù)器的數(shù)字證書(shū)包括web服務(wù)器的主機(jī)名和IP地址2.       有關(guān)申請(qǐng)證書(shū)的使用者的信息3.       有關(guān)CA頒發(fā)證書(shū)的詳細(xì)信息，包括證書(shū)有效性的信息，包括如何使用證書(shū)以及它的

3、有效期。例如，可能限制一個(gè)證書(shū)只用于加密文件系統(tǒng)，證書(shū)只在特定時(shí)間期有效，通常是兩年或更短，證書(shū)過(guò)期之后就不能再使用它了。Enhanced Key Usage是證書(shū)的一個(gè)可選的擴(kuò)展屬性，這個(gè)屬性包含一個(gè)目標(biāo)標(biāo)識(shí)符（OID），用于應(yīng)用程序或者服務(wù)。每個(gè)OID是一個(gè)獨(dú)特的數(shù)字序列。Key Usage: 證書(shū)允許主體執(zhí)行特定任務(wù)。為了幫助控制證書(shū)在其預(yù)定的目的以外的使用，限制自動(dòng)放置在證書(shū)。密鑰用法（Key Usage）就是一個(gè)限制方法來(lái)決定一個(gè)證書(shū)可以被用來(lái)干什么。它允許管理員頒發(fā)證書(shū)，它只能用于特定任務(wù)或用于更廣泛的功能。如果沒(méi)有指定密鑰用法，證書(shū)可以用于任何目的。對(duì)于簽名, key usage

4、可以有下列一個(gè)或者多個(gè)用途：1.       數(shù)字簽名2.       簽名一種起源的證據(jù)3.       證書(shū)簽名4.       CRL簽名2. CA證書(shū)頒發(fā)機(jī)構(gòu)CA是向用戶和計(jì)算機(jī)頒發(fā)數(shù)字證書(shū)的PKI組件，當(dāng)組織實(shí)現(xiàn)數(shù)字證書(shū)時(shí)，他們必須考慮是使用AD CS還是一個(gè)外部CA來(lái)實(shí)現(xiàn)。內(nèi)部CA的主要優(yōu)點(diǎn)是成本，對(duì)于頒發(fā)的每個(gè)證書(shū)都沒(méi)有額外成本。而如果使用外部

5、CA(三方CA)，每個(gè)頒發(fā)的證書(shū)都有一定費(fèi)用。CA的主要作用如下：1. 驗(yàn)證證書(shū)請(qǐng)求者的身份：當(dāng)一張證書(shū)頒發(fā)給一個(gè)用戶、計(jì)算機(jī)或者服務(wù)的時(shí)候，CA會(huì)驗(yàn)證請(qǐng)求者身份來(lái)確保證書(shū)只辦法給正確的用戶或機(jī)器2. 將證書(shū)辦法給用戶和計(jì)算機(jī)3. 管理證書(shū)吊銷情況：CA會(huì)定期發(fā)布CRL，CRL包含證書(shū)的序列號(hào)以及被吊銷的情況。3. 請(qǐng)求和頒發(fā)證書(shū)的過(guò)程用戶、計(jì)算機(jī)和服務(wù)請(qǐng)求和接收來(lái)自CA的證書(shū)。請(qǐng)求和接收證書(shū)的過(guò)程被稱為注冊(cè)。通常，用戶或計(jì)算機(jī)啟動(dòng)注冊(cè)通過(guò)提供獨(dú)特的信息，如電子郵件地址或通用名稱，和一個(gè)新生成的公鑰。在產(chǎn)生證書(shū)之前CA使用此信息來(lái)驗(yàn)證用戶的身份。1 生成密鑰對(duì)。 申請(qǐng)人生成一個(gè)公鑰和私鑰對(duì)，或

6、被組織的權(quán)威指定一個(gè)密鑰對(duì)。申請(qǐng)人將密鑰對(duì)存放在本地存儲(chǔ)的磁盤上或如智能卡的硬件設(shè)備2 申請(qǐng)人提供請(qǐng)求的證書(shū)模板所需的證書(shū)信息請(qǐng)求，并將它發(fā)送到CA。證書(shū)請(qǐng)求包括公共和私人密鑰對(duì)的公鑰生成請(qǐng)求的計(jì)算機(jī)3 證書(shū)管理器檢查證書(shū)請(qǐng)求驗(yàn)證信息?；谶@些信息，證書(shū)管理器頒發(fā)證書(shū)或拒絕證書(shū)請(qǐng)求4 CA創(chuàng)建并頒發(fā)證書(shū)給請(qǐng)求者。由CA簽名證書(shū)，以防止修改，包括請(qǐng)求者的身份信息和提交的公共密鑰作為頒發(fā)的證書(shū)的屬性。4. 證書(shū)鏈鏈建立是建立信任鏈的過(guò)程或者證書(shū)路徑，從最終證書(shū)以及安全實(shí)體信任的根證書(shū)。證書(shū)鏈的建立將會(huì)通過(guò)檢查從最終證書(shū)到根CA的每個(gè)證書(shū)路徑。會(huì)從中級(jí)證書(shū)頒發(fā)機(jī)構(gòu)存儲(chǔ)區(qū)，受信任的根證書(shū)頒發(fā)機(jī)構(gòu)存儲(chǔ)區(qū)

7、，或從一個(gè)證書(shū)的AIA屬性中指定的URL中檢索證書(shū)。如果加密應(yīng)用程序接口發(fā)現(xiàn)一個(gè)路徑中的證書(shū)有問(wèn)題，或者如果它找不到證書(shū)，證書(shū)路徑是會(huì)作為一個(gè)不受信任的證書(shū)路徑丟棄。證書(shū)鏈引擎生成所有可能的證書(shū)鏈。然后整個(gè)的證書(shū)鏈就生成了并按照鏈的質(zhì)量排序。對(duì)于給定的最終的質(zhì)量最好的證書(shū)鏈作為默認(rèn)的鏈返回給調(diào)用應(yīng)用程序。每個(gè)鏈都是通過(guò)結(jié)合證書(shū)存儲(chǔ)的證書(shū)和發(fā)布的URL位置的證書(shū)。鏈中的每個(gè)證書(shū)分配一個(gè)狀態(tài)代碼。狀態(tài)代碼指示證書(shū)是否符合下面的條件：1.       簽名是否有效2.      

8、時(shí)間是否合法3.       證書(shū)是否過(guò)期4.       證書(shū)是否已經(jīng)被吊銷5.       時(shí)間嵌套6.       證書(shū)上的其他限制每個(gè)狀態(tài)代碼都有一個(gè)分配給它的優(yōu)先級(jí)。例如，過(guò)期的證書(shū)具有更高的優(yōu)先級(jí)比吊銷的證書(shū)。這是因?yàn)檫^(guò)期的證書(shū)不檢查吊銷狀態(tài)。證書(shū)鏈中的所有證書(shū)都會(huì)被檢查是否吊銷。不管是什么過(guò)程來(lái)檢查證書(shū)的合法性，只要證書(shū)鏈中的狀態(tài)檢查失敗，這個(gè)

9、證書(shū)鏈就會(huì)被拒絕。對(duì)鏈中的每個(gè)證書(shū)，證書(shū)鏈引擎必須選擇一個(gè)頒發(fā)CA的證書(shū)。這一過(guò)程被稱為驗(yàn)證路徑，重復(fù)驗(yàn)證直到達(dá)到一個(gè)自簽名證書(shū)(通常，這是根CA證書(shū))。加密應(yīng)用程序接口對(duì)待根證書(shū)作為絕對(duì)信任的信任。5. Certificate Service組件的工作原理CA服務(wù)包括如下組件以及功能，請(qǐng)參考：Client Module: 負(fù)責(zé)提交證書(shū)申請(qǐng)Certificate Services Engine: 負(fù)責(zé)處理證書(shū)申請(qǐng)請(qǐng)求，負(fù)責(zé)創(chuàng)建和頒發(fā)證書(shū)給有效的申請(qǐng)者Policy module: 負(fù)責(zé)驗(yàn)證請(qǐng)求者是否有權(quán)獲得證書(shū)CryptoAPI and cryptographic service provide

10、rs：負(fù)責(zé)創(chuàng)建私鑰并分發(fā)給申請(qǐng)者的受保護(hù)的證書(shū)存儲(chǔ)exit module：負(fù)責(zé)分發(fā)證書(shū)給有效的客戶端，在網(wǎng)頁(yè)、公共文件夾、AD中發(fā)布證書(shū)，負(fù)責(zé)向AD中定期發(fā)布CRLsCryptoAPI：負(fù)責(zé)管理所有加密操作的私鑰certificates database:負(fù)責(zé)存儲(chǔ)所有的證書(shū)交易以及審計(jì)CA服務(wù)所使用的協(xié)議有DCOM和LDAPDCOM:用來(lái)進(jìn)行證書(shū)注冊(cè)LDAP:用來(lái)進(jìn)行域AD之間的交互證書(shū)創(chuàng)建的過(guò)程如下：· This process applies to most common PKCS #10 requests or Certificate Management protocol u

11、sing CMS requests.1. When a user initiates a certificate request, Enrollment Control (Xenroll.dll) uses a cryptographic service provider (CSP) on the clients computer to generate a public key and private key pair for the user. 當(dāng)用戶初始化證書(shū)請(qǐng)求的時(shí)候，CSP會(huì)創(chuàng)建出一個(gè)公鑰和私鑰對(duì)。2. After a key pair has been generated, Xen

12、roll builds a certificate request based on a certificate template. 密鑰對(duì)創(chuàng)建之后，會(huì)基于模板創(chuàng)建出一個(gè)證書(shū)請(qǐng)求3. The users public key is sent with the users identifying information to the Certificate Services engine. 用戶的公鑰以及身份信息會(huì)被發(fā)送給證書(shū)服務(wù)引擎4. Meanwhile, a copy of the request is placed in the request folder for the reques

13、ter. In the case of a user, this folder is: 同時(shí)，在本地保存一份請(qǐng)求C:Documents and SettingsusernameApplication DataMicrosoftSystemCertificatesRequest5. The CA authenticates the user. CA需要對(duì)用戶進(jìn)行驗(yàn)證6. The Certificate Services engine passes the request to the policy module, which might perform an additional access

14、check by querying Active Directory or another reliable source such as IIS. 證書(shū)服務(wù)引擎將請(qǐng)求發(fā)送給policy module, policy module負(fù)責(zé)到AD中請(qǐng)求進(jìn)行檢查。7. The policy module also checks the registry for a list of certificate templates for the CA. The policy module checks the list for version numbers to verify that it has th

15、e most recent versions of all certificate templates. If the request references a more recent version of the certificate template than is currently available, the request fails. Policy module負(fù)責(zé)檢查證書(shū)模板中的注冊(cè)表信息。8. If the access check is successful, the Certificate Services engine creates a new row in the

16、 Request and Certificates table of the certificates database. A request ID is entered into the database to help track the request. 訪問(wèn)檢查成功之后，請(qǐng)求號(hào)被存儲(chǔ)在數(shù)據(jù)庫(kù)中9. Additional attributes of the certificate request, such as the extensions associated with the request, are entered into the appropriate fields in t

17、he database.證書(shū)的其它相關(guān)屬性被寫入CA的數(shù)據(jù)庫(kù)中10. The Certificate Services engine validates the digital signature used to sign the certificate request. This validation process involves comparing all the certificates in the chain leading up to the root CA to a reliable source, such as Active Directory or IIS. This

18、validation process also involves confirming that none of the certificates in the chain has been revoked. 驗(yàn)證數(shù)字證書(shū)，檢查證書(shū)鏈11. The policy module applies a certificate template to fill out the data associated with the request. This process adds information such as usage restrictions and validity periods, a

19、s well as subject name format, to the data in the original request. Some of this data is fixed and therefore copied directly from the template, some comes from the certificate request, and some is constructed on a per user basis (concatenating the friendly name of the user into common name format, f

20、or example).Noteo When a certificate is being renewed, data that is not being modified is simply reused. 12. If a certificate template has been set to pending, an administrator must verify related information in the request such as the identity of the requester which is not controlled by the policy

21、module. 檢查證書(shū)模板13. The policy module returns the request to the Certificate Services engine, noting whether the request should be issued, should be denied, or is pending. 檢查該證書(shū)是否應(yīng)該被頒發(fā)14. If the request has been approved, the Certificate Services engine constructs the certificate with the appropriate

22、subject, validity period, and extensions. 如果請(qǐng)求被批準(zhǔn)，則將相關(guān)的信息放置在證書(shū)中生成一張證書(shū)15. The Certificate Services engine encodes, signs, and validates the certificate from information in the database to verify that the certificate is valid for the entire certificate chain and all defined purposes, and performs anot

23、her revocation check before it issues the certificate.16. The issued certificate is sent to the exit module, which saves the certificate to the certificates database and, depending on the template configuration, publishes it to the directory service. Noteo If this is a local forest, the certificate

24、is published to the user object. If this is a forest trust, the certificate is published to the contact object. 17. The exit module constructs and signs a response, which is returned to Xenroll.dll on the client. This response can include: o A CMS response.o A certificate BLOB.o A message indicating whether the certificate request has been approved, has been denied, or is pending.o An error message.o Request ID.Xenroll places the certificate in the f