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

SSL證書的基本知識

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

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

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

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

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

通配符證書

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

主機備用名稱

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

• CN = *.foo.com

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

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

中間CA

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

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

證書管理

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

微軟.PFX文件捆綁密鑰

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

PEM和DER編碼

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

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

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

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

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

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

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

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

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

驗證導(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

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

解決證書管理問題

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

檢查私鑰文件：

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

檢查CSR：

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

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

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

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

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

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

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

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

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