很多網(wǎng)絡(luò)工程師面對(duì)瑣事之一是SSL證書的維護(hù)和更新。對(duì)于筆者而言，SSL證書主要是用于VPN部署，但也有很多網(wǎng)絡(luò)設(shè)備需要證書來加密客戶端到服務(wù)器的通信。每當(dāng)筆者聲稱需要一個(gè)證書時(shí)，大家都會(huì)變得鴉雀無聲，可能對(duì)于大多數(shù)人來說，證書有點(diǎn)恐怖。畢竟很多使用公鑰加密技術(shù)的現(xiàn)有資源要么處于“保密”狀態(tài)，要么使用對(duì)于實(shí)用主義來說過于抽象的原則。本文的目的就是解決這方面的困惑，介紹SSL證書的基本知識(shí)和一些常見的現(xiàn)實(shí)例子。

SSL證書的基本知識(shí)

Web服務(wù)器和相關(guān)設(shè)備使用的常見證書主要由三部分組成：

• 主體私鑰。這包含關(guān)于主體的獨(dú)特的可識(shí)別信息，這通常是Web服務(wù)器，但也可能是個(gè)人用戶。私鑰通常在主機(jī)本身上生成，理論上永遠(yuǎn)不會(huì)離開操作系統(tǒng)密鑰存儲(chǔ)區(qū)。在生成私鑰時(shí)，也產(chǎn)生了一個(gè)證書簽名請(qǐng)求。

• CA公鑰：證書頒發(fā)機(jī)構(gòu)(CA)是各方信任的一臺(tái)服務(wù)器?，F(xiàn)在有很多證書頒發(fā)機(jī)構(gòu)提供證書服務(wù)，例如DigiCert或者VeriSign。此外，這可能是私人CA，例如微軟Windows Server操作系統(tǒng)中的CA。如果在連接客戶端(無論是Web瀏覽器還是操作系統(tǒng)本身)的證書庫(kù)中存在其公鑰的副本，則該CA被認(rèn)為是可信的。

• 主體公鑰。當(dāng)CA對(duì)從私鑰生成的CSR文件中的信息簽名時(shí)，將會(huì)產(chǎn)生公鑰。該公鑰被設(shè)計(jì)為被透明地傳輸，并包含驗(yàn)證真實(shí)性和驗(yàn)證使用方法(例如服務(wù)器或客戶端身份驗(yàn)證)的簽名。

當(dāng)我們的主體服務(wù)器接收到連接請(qǐng)求時(shí)，它將會(huì)出示其簽名的公鑰，以便客戶端可以驗(yàn)證其身份。如果客戶端信任我們的公鑰，就會(huì)考慮加密，而公鑰將被用于加密客戶端的會(huì)話密鑰。這個(gè)會(huì)話密鑰只能由我們的私鑰進(jìn)行解密，并且可以完成其余安全套接字連接。

通配符證書

在創(chuàng)建私鑰時(shí)，公用名(CN)將被指定，在大多數(shù)情況下，這是主機(jī)的完全合格域名(FQDN)，例如www.foo.com。如果很多服務(wù)器需要保護(hù)，更經(jīng)濟(jì)且更實(shí)用的做法是對(duì)給定域的所有數(shù)據(jù)創(chuàng)建通配符證書(wildcard certificate)。當(dāng)你在邏輯主機(jī)(例如負(fù)載均衡器)上需要多個(gè)虛擬身份(例如www.foo.com, mail.foo.com以及ssl.foo.com)時(shí)，這也是非常有用的。在密鑰生成時(shí)，并不是為特定主機(jī)使用單個(gè)FQDN，而是主機(jī)部分被通配符取代，例如*.com。因此，該證書對(duì)于DNS域的所有事物都是有效的，但并不包括所有子域。大多數(shù)現(xiàn)代客戶端瀏覽器支持通配符，但你可能會(huì)碰到少數(shù)例外，例如嵌入式瀏覽器或早期版本的IE瀏覽器。

主機(jī)備用名稱

一個(gè)相對(duì)抽象但很有用的功能是主體備用名稱(SAN)。如果你需要通配符證書的功能，而又需要來自傳統(tǒng)客戶端的連接，一些CA會(huì)使用一些有效的備用名稱來簽名主體公鑰。即使是老舊的客戶端SSL部署也支持這個(gè)功能，這允許主體公鑰域這樣替換名稱：

• CN = *.foo.com

• SAN = www.foo.com, mail.foo.com, ssl.foo.com

即使客戶端不明白主體通用名稱中的通配符，它還是會(huì)匹配一個(gè)備用名稱并接受該證書的有效性。

中間CA

絕大多數(shù)客戶端證書不是由根級(jí)CA發(fā)出，而是由中間證書頒發(fā)機(jī)構(gòu)(intermedia CA)發(fā)出。從本質(zhì)上講，根級(jí)CA對(duì)中間CA的公鑰進(jìn)行簽名，允許其代替它簽名證書。這種授權(quán)簽名可能會(huì)發(fā)生幾次，你最后得到的證書可能經(jīng)歷了幾層證書機(jī)構(gòu)。在下面的例子中，主體的證書“www.amazon.co.uk”由VeriSign Class 3 Secure Server CA-G2簽名，而這又是由VeriSign根證書來簽名的。

常見的中間級(jí)證書被嵌入在客戶端證書存儲(chǔ)區(qū)，但很多來自互聯(lián)網(wǎng)服務(wù)提供商或域名注冊(cè)商的合法中間證書并不是這樣。中間證書需要被連接到Web服務(wù)器，這樣客戶端就可以循著證書鏈直到找到由可信CA簽名的證書。在筆者的經(jīng)驗(yàn)來看，這解釋了為什么當(dāng)用戶連接到有付費(fèi)證書的網(wǎng)站仍然遇到證書信任錯(cuò)誤的原因。證書頒發(fā)機(jī)構(gòu)提供根和下屬公鑰的捆綁，你需要將其導(dǎo)入到Web服務(wù)器配置。很多CA提供在線工具來檢查中間證書是否被正確安裝。當(dāng)導(dǎo)入你的簽名公鑰時(shí)，你有必要檢查中間證書是否需要注意避免必然的支持呼叫。

證書管理

OpenSSL加密工具包是工程師管理證書的“秘密武器”。這些二進(jìn)制文件被包含在大多數(shù)*nix版本中，同時(shí)，也可用于Windows。這個(gè)強(qiáng)大的工具很值得我們學(xué)習(xí)，這樣我們就不需要記住多個(gè)平臺(tái)的本地證書管理的細(xì)微差別。精簡(jiǎn)版本就能夠滿足大多數(shù)日常需求。

微軟.PFX文件捆綁密鑰

PFX文件主要用于微軟環(huán)境，在通常情況下，密鑰在Windows中生成，然后由域集成CA自動(dòng)對(duì)其簽名。這是有用的，因?yàn)檫@個(gè)私鑰、簽名的公鑰和CA公鑰被捆綁成單個(gè)文件。這個(gè)密鑰可以選擇通過密碼來加密，當(dāng)你在公共網(wǎng)絡(luò)傳輸證書時(shí)，這可以提供某種程度的保護(hù)。通過使用OpenSSL，單個(gè)組件可以被導(dǎo)出和轉(zhuǎn)換。此外，這些文件不包含人類可讀部分。

PEM和DER編碼

常見x.509v3證書通過兩種格式編碼：PEM或者DER，并且通常會(huì)被授予.CRT或者.CER的文件擴(kuò)展名。這些文件擴(kuò)展名本身并不會(huì)讓你知道它們的格式，因?yàn)樗鼈兪腔Q使用的，但其內(nèi)容可以給你一些提示。PEM文件是Base-64 ASCII編碼，前綴為“---- BEGIN CERTIFICATE ----”，后綴為“---- END CERTIFICATE ----”。DER文件是二進(jìn)制編碼，不是人類可讀的。

當(dāng)從Windows導(dǎo)出證書時(shí)，你可以選擇三種格式：DER、PEM和P12，但是具體使用哪種并不清楚。

很多網(wǎng)絡(luò)設(shè)備需要證書和密鑰以PEM格式導(dǎo)入，但Windows MMC證書管理單元只允許私鑰以P12格式導(dǎo)出。這僅僅是成功的一半，因?yàn)槟氵€需要提取簽名的主體的公鑰。

從PEX文件以PEM格式提取公鑰

導(dǎo)出的主體公鑰清楚地顯示了發(fā)出該公鑰的服務(wù)器的名稱，以及簽名該公鑰的根級(jí)CA的名稱。你必須檢查你是否在操作正確的證書(例如由商業(yè)CA而不是內(nèi)部域CA簽名的證書)。

為了逆轉(zhuǎn)這個(gè)過程，并將私鑰，公鑰和CA證書結(jié)合成單個(gè)文件，你需要使用以下命令：

C:\cert>openssl pkcs12 -export -out NewPfx.pfx -inkey justPrivateKey.key -in justPublicKey.crt -certfile CACert.crt

加載“屏幕”到隨機(jī)狀態(tài)—完成

輸入導(dǎo)出密碼： <設(shè)置新密碼>

驗(yàn)證導(dǎo)出密碼： <重復(fù)新密碼>

PEM和DER之間的轉(zhuǎn)換

另一種常見的要求是轉(zhuǎn)換PEM編碼的文件為DER編碼：

C:\cert>openssl x509 -outform der -in justPublicKey.pem -out justPublicKey.der

然后，將其轉(zhuǎn)換回來：

C:\cert>openssl x509 -inform der -in justPublicKey.der -out justPublicKey.pem

值得注意的是，這個(gè)過程通常會(huì)去除純文本擴(kuò)展屬性，只在“---- BEGIN CERTIFICATE ----”和“---- END CERTIFICATE ----”緩沖區(qū)之間剩下原始證書。

解決證書管理問題

不可避免的是，你將遇到某些東西無法正常運(yùn)行的情況。如果遇到這種情況，第一個(gè)步驟是使用OpenSSL的本地工具來檢查你的密鑰和證書的格式是否正確。

檢查私鑰文件：

C:\cert>openssl rsa -in justPrivateKey.key –check

檢查CSR：

上面的例子清楚地顯示了整個(gè)證書主體。這里的兩個(gè)密鑰組件是“O=”(Organization企業(yè))和“CN=”(Canonical Name，規(guī)范名稱)。企業(yè)字段中必須與你的注冊(cè)機(jī)構(gòu)名稱完全相同。例如，如果你公司注冊(cè)名稱是“Foo Company Plc(UK)”，如果你提交“Foo Company UK”將會(huì)被拒絕。此外，證書中指定的域名必須是由你或授權(quán)第三方注冊(cè)的。

驗(yàn)證證書(PEM或者DER格式)：

C:\cert>openssl x509 -in CACert.crt -text –noout

在下面的實(shí)例中，筆者分析了VeriSign CA公鑰，可以從中收集很多有效信息：

• 證書有效日期。所有證書在其需要重新簽名前都有一個(gè)有效性窗口。Web服務(wù)器證書的有效期一般為不超過三年，而CA證書往往是10年或以上。一個(gè)沒有經(jīng)驗(yàn)的網(wǎng)絡(luò)管理員可能會(huì)通過有效期為一年的證書來創(chuàng)建域根級(jí)CA。在這種情況下，CA根證書很快會(huì)過期并失效，即使簽名的證書的有效期更長(zhǎng)。

• 密鑰強(qiáng)度。RSA密鑰有給定的強(qiáng)度：使用的位數(shù)越多，就越難以猜測(cè)。很多公共CA現(xiàn)在只簽署2048位密鑰，但是，1024甚至512位密鑰用于內(nèi)部應(yīng)用程序的情況也不少見。

• 密鑰用途。除非你是做一些模糊的事情，否則至少這應(yīng)該包括傳輸層安全Web服務(wù)器身份驗(yàn)證和TLS Web客戶端身份驗(yàn)證。

• 證書吊銷列表(CRL)和在線證書狀態(tài)協(xié)議(OCSP)分發(fā)點(diǎn)。一些客戶端會(huì)對(duì)證書進(jìn)行更多的實(shí)時(shí)檢查，以確保它們沒有通過使用靜態(tài)CRL或者動(dòng)態(tài)OSCP協(xié)議被吊銷。公共CA對(duì)這些服務(wù)提供公開訪問，但私有CA可能沒有對(duì)這些服務(wù)正確地配置或者不允許遠(yuǎn)程客戶端訪問。

• 主體備用名稱。正如前面所討論的，SAN允許證書擁有幾種不同的身份證書。所有配置的SAN也許可以解釋為什么主體名稱明顯不同時(shí)，證書也可以通過驗(yàn)證。