圖1 請求證書
數字簽名(創(chuàng)建消息，創(chuàng)建者密封了真實性)
密鑰加密(對于諸如“加密文件系統(tǒng)”這樣的技術，使用一個密鑰保護另一個密鑰)
保護郵件(只有擁有相應私鑰的目標收件人才能閱讀加密郵件)
發(fā)送 S/MIME 簽名的電子郵件時并不需要密鑰加密屬性。但在發(fā)送或接收加密郵件時則需要這個屬性，但不需要簽名屬性。默認情況下，Windows® 證書服務中的模板啟用這三個屬性。如果不允許用戶申請新證書，則向導啟動時三個屬性都不會顯示。如果沒有任何企業(yè) CA 可用，會向用戶顯示“注冊錯誤”，指明無法聯(lián)系域或 CA。對于此演練，我們將假設單一證書同時允許簽名和加密。
交換證書
兩個用戶開始發(fā)送加密電子郵件的最簡單方法就是彼此直接傳送已簽名的郵件。撰寫好郵件之后，用戶可單擊“簽名”按鈕。(有時候除非至少用過一次，否則在 Outlook 中會默認隱藏這個按鈕?？梢酝ㄟ^依次單擊新郵件的“選項”設置、“安全設置”按鈕，然后選中“安全屬性”對話框上的“為此郵件添加數字簽名”框找到該按鈕)。簽名按鈕(帶有紅色緞帶的黃色小信封，寫著“簽名”)會將數字簽名添加到郵件中以建立它的來源真實性。
按下“發(fā)送”按鈕之后，可能會提示用戶提供另外持有的密鑰令牌，如插入智能卡或輸入 PIN。這會視組織中所采用的特定密鑰保護方法而定。
收到 S/MIME 簽名郵件的用戶需要查看并右鍵單擊發(fā)件人名稱(發(fā)件人: 之后)，然后從上下文菜單中選擇“添加到 Outlook 聯(lián)系人”來添加新的聯(lián)系人項或更新現(xiàn)有聯(lián)系人。證書隨后會與該特定的聯(lián)系人項建立關聯(lián)。請注意，在常見的 Active Directory 環(huán)境中(兩個用戶位于相同的林或公司中)，公用用戶證書分發(fā)是通過用戶的 Active Directory 對象中的屬性自動完成的。
交換證書的另一種方法是每個用戶以附件的形式發(fā)送其 S/MIME 證書。為此，雙方都必須將其證書導出為 CER 文件。用戶需要查看證書，并遵循我們即將討論的導出過程，注意不要使用該導出過程導出私鑰，如圖 2 所示。
圖2 交換證書時，不要導出私鑰
每個收件人接下來會在 Outlook 中手動創(chuàng)建聯(lián)系人項，然后將證書添加到該發(fā)件人項中。兩個用戶交換證書后，他們就能夠彼此交換加密的電子郵件了。
疑難解答
有時收件人會無法打開加密的郵件。對于在這個領域中出現(xiàn)的問題，最有可能的三個原因分別是根 CA 不受信任、無法驗證中間 CA 以及無法使用 CRL。
不受信任的根CA 通常會在Outlook中顯示為與簽名相關聯(lián)的錯誤消息：“該簽名有問題。單擊簽名按鈕可獲取詳細信息。”若要解決問題，請從Outlook中打開證書，然后單擊彈出對話框中的“查看證書頒發(fā)機構”按鈕。查看證書屬性對話框“常規(guī)”選項卡上的消息。如果消息指示CA根證書不受信任，而且需要安裝，請轉到“詳細信息”選項卡。單擊“復制到文件…”按鈕，并按照向導說明進行操作，接受所有默認設置并在收到提示時提供文件名和文件夾。
現(xiàn)在以計算機管理員的身份打開一個新的 Microsoft 管理控制臺(MMC)。轉到“文件”|“添加/刪除管理單元(Ctrl+M)”，選擇“證書”，并添加它以用于計算機帳戶，在提示時選擇“本地計算機”。接下來，在左邊樹狀結構中展開“證書”節(jié)點，然后對“受信任的根證書頒發(fā)機構”執(zhí)行相同的操作。右鍵單擊并從彈出菜單中選擇“所有任務”|“導入”。將前述導出的證書文件導入到“受信任的根證書頒發(fā)機構”并單擊“完成”。然后讓受影響的用戶重新啟動Outlook。
應該僅使用上述說明添加已知的受信任根CA。并不是創(chuàng)建的所有根CA 都是平等的。請先審慎考慮是誰擁有和操作根CA，再使用該方法將根證書添加到整個系統(tǒng)的存儲區(qū)。如果企業(yè)通過組策略控制受信任的根CA 列表，則會將配置推送到客戶端系統(tǒng)。在這種情況下，上述的說明可能并不適用。如果事實如此，您可能需要探索其他替代辦法，如確保網站或服務器的安全以交換數據，因為使用電子郵件的體驗并不順暢，也不會受到保護。
上面提出的第二個問題，即無法驗證中間CA，通常在兩種情況下發(fā)生：嘗試驗證證書的客戶端無法到達證書中所定義的頒發(fā)機構信息訪問(AIA)位置，或者客戶端所擁有的中間CA 證書版本與CA 所頒發(fā)的版本不符(客戶端通常晚于一兩個版本)。這些情況在Outlook用戶界面中看起來十分類似。我們只在非常特殊的情形下看到過這種情況，就是當信任鏈中的中層 CA 已過期，并在它頒發(fā)的其他從屬證書到期之前重新頒發(fā)。
基本上，這個問題發(fā)生在信任鏈中存在中斷的情況下。有些父證書可能不具備完善的詳細資料或者沒有適當內嵌在葉節(jié)點中，進而使整個情況更加復雜。
若要解決此問題，發(fā)件人需要打開新郵件，并依次單擊新郵件的“選項”、“安全設置”按鈕以及“更改設置”按鈕?，F(xiàn)在單擊適用于簽名證書的“選擇”按鈕，然后單擊彈出對話框上的“查看證書”按鈕。轉到“證書路徑”選項卡，選擇葉節(jié)點的頒發(fā)者(也就是在信任鏈中往上一層)，然后單擊“查看證書”按鈕。依次單擊“詳細信息”選項卡、“復制到文件…”按鈕，然后完成導出向導，選擇PKCS #7(.P7B)。確定已選中“包括證書路徑中所有證書”選項，如圖 3 所示。最后，將導出的信任鏈文件發(fā)送到目標收件人。
圖3 修正證書鏈中的中斷
獲得導出的證書鏈后，收件人需要打開并導出信任鏈，做法跟我們之前導入根證書相似。一個區(qū)別是所選的存儲文件夾應該是“中間證書頒發(fā)機構”。如果郵件已打開并且證書在Outlook中顯示為有效，則一切都會適當運作。
至于第三個問題，即無法使用CRL，解決方法相對簡單。Outlook 的最初響應看起來與前一個問題非常相似。不過，即使根或中間簽名CA是受信任的，也會顯示錯誤。對于證書鏈中葉節(jié)點以上的每個級別，請依次打開證書的屬性和“詳細信息”選項卡，然后查看稱為“CRL 分發(fā)點”的字段。
對于列出的每個CRL分發(fā)點(尤其是Internet可以訪問的分發(fā)點)，確保CRL文件URL可以打開。驗證完每個級別則在信任鏈中向上移動一個級別。如果有任何CRL無法獲得，則它可能是問題的根源。若要解決問題，您應該確認本地網絡策略并沒有阻止您的訪問。否則，請嘗試與擁有CA的公司聯(lián)系或等待CA的CRL分發(fā)點恢復正常運作狀態(tài)。
分發(fā)證書
分發(fā)是非常簡單的過程。基本上，已簽名的郵件傳輸到郵件服務器，該服務器然后通過可靠的方法(即SMTP)將它從一個位置傳送到另一個位置。對于傳輸中的已簽名或已加密郵件，我們發(fā)現(xiàn)的一個問題是，有些郵件系統(tǒng)會拒絕或中斷通過它們的已簽名或已加密郵件。解決方法是與系統(tǒng)的 IT 經理合作來允許這些郵件類型。當然，您可能不得不接受某些郵件類型會被阻止的事實。接收方可能有正當的理由在特定的操作環(huán)境下不允許加密郵件。
加密回復
若要創(chuàng)建加密回復(假設上述啟動過程已完成)，發(fā)件人只需要新建郵件，然后在郵件撰寫窗口中單擊“加密”按鈕(帶有藍色鎖的黃色小信封，寫著“加密”)。如果“加密”按鈕不可用，請按照發(fā)送已簽名郵件的步驟(最后一步除外)，選中“加密郵件內容和附件”復選框。
將加密郵件發(fā)送到收件人并不需要 S/MIME 簽名，但是兩者搭配也無妨，因為簽名可使讀者驗證發(fā)件人(加密功能并不會對發(fā)件人進行任何聲明)。加密過程將嘗試使用所有收件人已知的公鑰來加密郵件。如果系統(tǒng)無法找到某些指定收件人的證書，則會在彈出對話框中將其標示出來，建議向其發(fā)送未加密郵件，如圖 4 所示。
圖4 如果您使用證書時遇到問題，可決定發(fā)送未加密的郵件
默認情況下，簽名和加密應該與其他同等配置的客戶端系統(tǒng)搭配使用，但是如果哈?；蚣用芩惴ú恢С窒聦拥脑挘袝r跨版本加密或簽名郵件可能會產生問題。我們在將經過簽名的電子郵件(使用 SHA-512 作為哈希算法)發(fā)送到運行 Windows XP SP2 的用戶時，會遇到這樣的問題。因為接收系統(tǒng)并不支持哈希，所以用戶無法驗證簽名或閱讀郵件。但是，除非 Outlook 默認值有所更改，否則用戶不可能在這個階段遇到太多問題。
收到郵件后，假如與共用證書相關聯(lián)的私鑰可用，目標收件人應該能夠打開郵件。此外，用戶可能需要提供其他令牌以證明持有私鑰，具體取決于私鑰的部署方式。已完成類似啟動過程的其他用戶可與發(fā)件人進行類似的簽名和加密通信。如果用戶更改了他的私鑰(也許是因為計算機遺失)，他必須重新請求證書，然后將簽名郵件或證書文件重新分發(fā)到想要交換加密郵件的其他人。
總結
使兩個不同目錄或組織中的兩名用戶之間能夠進行簽名和加密的S/MIME通常不會比我們剛剛所討論的復雜多少。簽名在使用得當時非常實用，因為它可增加郵件的真實性。對于敏感的詳細信息，加密郵件為傳輸中的數據提供另外一個級別的安全保護。兩者結合可實現(xiàn)來源的真實性和數據的秘密性。通過我們在本文中對過程的介紹，對于大多數用戶來說，利用這些功能應該不成問題。
