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

SSL證書的基本知識

Web服務器和相關設備使用的常見證書主要由三部分組成：

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

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

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

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

通配符證書

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

主機備用名稱

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

• CN = *.foo.com

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

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

中間CA

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

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

證書管理

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

微軟.PFX文件捆綁密鑰

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

PEM和DER編碼

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

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

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

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

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

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

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

加載“屏幕”到隨機狀態—完成

輸入導出密碼： <設置新密碼>

驗證導出密碼： <重復新密碼>

PEM和DER之間的轉換

另一種常見的要求是轉換PEM編碼的文件為DER編碼：

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

然后，將其轉換回來：

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

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

解決證書管理問題

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

檢查私鑰文件：

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

檢查CSR：

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

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

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

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

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

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

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

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

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