The Will Will Web

記載著 Will 在網路世界的學習心得與技術分享

S/MIME 簽章郵件在 Outlook 中出現警告訊息的問題詳解

📅 2009/07/21 13:05 📁 Office, Tips, 系統管理

我之前為了將從網站發出的郵件加上 S/MIME 簽章而傷透腦筋，從頭跌跌撞撞到尾，從來沒有任何一個環節是「順利」的，本想說終於都發送成功了，卻又被客戶發現一個我之前沒發現的問題，而這問題也是困擾我一個多月，經過不斷上網找資料並求證後，終於給我找到點蛛絲馬跡。

我們原本將信件順利寄到客戶的 Outlook 中，而且郵件與簽章都正確無誤，如下圖示：

我們原本將信件順利寄到客戶的 Outlook 中，而且郵件與簽章都正確無誤

如果點選「簽章」會出現 “數位簽章: 有效”的對話框，感覺也很順利，如下圖示：

數位簽章: 有效 - 此郵件的數位簽章為 [有效] 且 [受信任的]。 

但如果再點選「詳細資料」按鈕，就會出現一個討人厭的「驚嘆號」圖示，並在描述欄會出現”警告: 「憑證撤消清單」需要驗證簽名憑證是無法使用或是已過期。”的訊息，如下圖示：

郵件安全性內容 - 警告: 「憑證撤消清單」需要驗證簽名憑證是無法使用或是已過期。

我又再次被擊倒，因為無法回答客戶「為什麼」。我先講「如何解決問題」（其實也不算真正解決），再說「為什麼」。

解決的方式只有一種，就是先點選「編輯信任」按鈕，然後切換到「信任」頁籤，並選取 編輯信任選項 的 [明確宣告信任這個憑證] 選項，下次再開啟同一個簽章簽名過的 S/MIME 郵件就會 "完全信任" 了。

檢視憑證 - 信任 - 選取 編輯信任選項 的 [明確宣告信任這個憑證] 選項

問題發生原因

由於複雜的憑證驗證機制中有一個憑證撤銷的狀況，由於發出的憑證可能會因為遺失或被人惡意濫用而申請「撤銷(Revocation)」，所以通常驗證卡片的電腦都需要定時向發證單位(CA)取得 憑證撤消清單(CRL; Certificate revocation list) 用以得知該憑證是否「真的有效」。（備註: CRL 是一個網址）

如果想要查詢該簽章所列出的 CRL 位址，可以在點選「編輯信任」按鈕後，切換到「詳細資料」頁籤，並找到 “CRL 發佈點” 項目即可看到 CRL 網址：

在點選「編輯信任」按鈕後，切換到「詳細資料」頁籤，並找到 “CRL 發佈點” 項目即可看到 CRL 網址

通常這個網址是可以手動下載的，我將下載後的 complete.crl 檔案手動安裝進憑證儲存區：

手動安裝 CRL 檔

並且進入憑證管理員查看「憑證撤銷清單資訊」，也確定都要安裝成功（如下圖）：

憑證管理員 --> 憑證撤銷清單資訊

但 Outlook 2007 依然無法正確下載並驗證這個簽章的有效性。

最後我在 MOICA內政部憑證管理中心 的 問答集 的 0504 保密電子郵件設定 項目中發現了一篇 MOICA保密郵件暨應用說明操作手冊下載(PDF) 文件，文件標題為「內政部憑證管理中心 自然人憑證之保密郵件設定暨應用說明操作手冊 Ｖ2.0」。

MOICA內政部憑證管理中心 的 問答集 的 0504 保密電子郵件設定 項目

MOICA保密郵件暨應用說明操作手冊下載

該文件的倒數第 2 頁有一篇內容如下：

五、收到對方寄來的保密郵件，憑證仍在有效期限內但卻顯示簽章有問題?

欲檢驗憑證目前的狀態及效期，必須經由取得內政部憑證管理中心的憑證廢止清冊(CRL)
來進行憑證撤銷檢查，但由於 Outlook 及 Outlook Express 等收信軟體中關閉了數位識別碼
的檢驗功能，以致無法在保密郵件寄逹時經由收信軟體直接進行檢驗。使用者可經由檢視
憑證詳細內容的方式來確認寄件者的憑證狀態及效期，再以編輯信任的方式將該連絡人加
入信任的清單之中，未來收到該連絡人寄來的保密郵件時就不會出現簽章有問題的情況了。

我想這應該是這就是問題所在吧，但我還是不甘願就此打住，這是 GCA 單方面的說法，他們把罪都怪到微軟頭上。但我心裡是覺得「數位識別碼驗證」這個這麼基本的功能怎麼可能會關閉，應該是哪個環節出錯了。

在詢問微軟之後，他請我修正機碼（如下說明），但我修正後依然無法解決問題。

您可以透過下列registry Key的方式來控制Outlook CRL的檢查

Office 2003
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security\

Office 2007
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Security\

在上述的路徑中新增一個DWORD 名稱為"UseCRLChasing"的registry key值
並修改此"UseCRLChasing"的值為0,1,2

0 = While online, check for Certificate Revocation
1 = Check for Certificate Revocation, even when offline (this is the default value)
2 = Never check for Certificate Revocation

完成上述值之後請重新開機生效.
請注意,即使您設定Outlook Allways去檢查CRL也不代表可以解決您的問題.
因為,還必需要配合核發該憑證簽章的CA Server有定期的去更新其CRL
也就是說如果該CRL已經過期,那麼Outlook 去檢查到的結果也會是過期的結果.

因為還是無法解決問題，我又找到了 Troubleshooting Certificate Status and Revocation 這篇文章，這才瞭解 CRL 機制是跟著每一個應用程式走的，也就是應用程式是否啟用 CRL 並非由 Windows 所決定，而是看各應用程式是否有實做，像是 IIS, Encrypting File System, Outlook, ... 都有各自的設定方法，但知道這個常識好像也於事無補。

最後，我將郵件中的憑證另存成 *.cer 檔，並利用 CertUtil 工具驗證憑證的有效性，若在 Windows XP 下可先下載 Windows Server 2003 Service Pack 2 系統管理工具包 x86 版 安裝，才會有 CertUtil 程式。

請參考以下指令進行憑證驗證：

certutil -verify -urlfetch RDEC.cer > RDEC_Verify.txt

在最後的幾行得到以下內容: 【因為撤銷伺服器已離線，無法完成撤銷檢查。】

因為撤銷伺服器已離線，無法完成撤銷檢查。 0x80092013 (-2146885613)
------------------------------------
419.3401.0: 0x80092013 (-2146885613)
Revocation check skipped -- server offline

ERROR: Verifying leaf certificate revocation status returned 因為撤銷伺服器已離線，無法完成撤銷檢查。 0x80092013 (-2146885613)
CertUtil: 因為撤銷伺服器已離線，無法完成撤銷檢查。

CertUtil: -verify command completed successfully.

所以，這是代表問題在 GCA 身上嗎？

我上週發了封信給 政府憑證管理中心(GCA) 詢問這個問題，但他們很有禮貌的到現在連一封信都不回我，擺明要我死心，真佩服政府的效率與服務品質。

但經過小道消息得知，GCA 他們認為這是微軟的問題，但 GCA 可以透過一些方法解決這個羅生門的問題，不過可能要等到明年才有機會解決這個問題。有沒有微軟的同仁可以協助釐清一下到底是誰的問題，我已經投降了，希望這篇文章可以讓相關人士瞭解真正問題所在。

﹡﹡﹡本日補充 ﹡﹡﹡

這篇文章果然奏效，微軟很有效率的將問題反應至美國，不到 12 小時的時間就有了標準解答。而且真的就這麼巧，今天文章剛發，下午 GCA 就來電來協助我解決這個問題，只是負責這部分的工程師不在，要等明天才會回覆我。

以下是我剛剛才收到微軟的原文回覆內容（英文）

----------

I had fully checked the command output and basic and Delta CRL downloaded from the web site.

The root cause is there is a programming error in Certificate Authority of政府憑證管理中心. There is no solution from Microsoft side.   Here is the detailed findings:

  1. The reported error is “錯誤: 確認分葉憑證撤銷狀態傳回 因為撤銷伺服器已離線，無法完成撤銷檢查。 0x80092013 (-2146885613)”.
  2. The above error message was caused by the following issue.
     ---------------- 憑證 CDP ----------------
  3. I downloaded the Delta CRL which is still valid and will be retired before 2009年7月21日 0:00:00.
  4. However, the delta CRL doesn't match the basic CRL as the "Delta CRL Indicator" in Delta CRL is different with "CRL number" in Basic CRL. Please check the screenshot for details. 
    (備註: 點選下圖可放大顯示) 
the delta CRL doesn't match the basic CRL as the “Delta CRL Indicator” in Delta CRL is different with “CRL number” in Basic CRL (備註: 點圖可放大顯示)

To resolve this issue, the 政府憑證管理中心 need correct its application and ensure "Delta CRL Indicator" in Delta CRL is same with "CRL number" in Basic CRL.

微軟這邊已經提出解決方案，接下來就等 GCA 接招了，真希望問題能解決，加油啦！

----------

2009-07-29 更新

今天終於收到 GCA 的回覆了，內容如下：

感謝您的來信,釐清如下:

1.現況說明:

有關 Complete CRL 及 Delta CRL 的相對關係，目前國際標準並未明確規範必須採用哪一種編排方式。因此 GPKI 之 Delta CRL Scheme 與微軟預期的不同，並無對錯之分。另也由於編排方式不同，並不適宜拿非 GPKI 體系之憑證來與GCA憑證比較。

2.警告訊息之處理方式:

FreshestCRL 擴充欄位是乃非必要檢查(non-critical)的欄位，所以 Windows 的憑證驗證模組是可以忽略 Delta CRL 而只依賴Complete CRL來檢查憑證狀態
註：GPKI的Complete CRL是每天更新，故即使 Windows 的憑證驗證模組只依賴 Complete CRL 來檢查證狀態，仍符合安全性。

3.相關資訊:

您所需的 RFC5280 規範：http://www.ietf.org/rfc/rfc5280.txt

另補充如下:

微軟的憑證驗證模組在比較 CRL Number 時，是把 CRL Number 當成 4 bytes (即 32 bits) 的一般 Integer 來相比，而由於我們的 CRL Number 長度為 7 bytes (符合 RFC5280)，導致於微軟的憑證驗證模組在比較 CRL Number 時發生錯誤，結果無法繼續執行其檢驗 CRL 的演算法，因而 Windows 的憑證驗證模組會回報 Outlook 軟體說無法正常查驗 CRL，因此在Outlook畫面上會出現警告訊息。

政府憑證管理中心 敬上

GCA 提出詳細的技術資訊真不錯，接下來就等微軟技術支援中心接招了，Go~ Go~ Go~ ^_^

----------

2009-07-30 更新

微軟技術支援中心已經確認目前 Outlook 可接受憑證的格式 CRL Number 為 4 bytes，的確與 GCA 目前發放採用 7 bytes 的演算上有不相容之處，他們提供我以下三種建議：

  • 改採用 Windows Server CA 取代您原來使用的 CA 憑證 ( 註: 應該不太可能 )
  • 改變 Outlook 設計，這個部份必需要是 Premier 合約的客戶才能提出 Design Change Request ( 註: 我沒有 Premier 合約，沒辦法提出修改設計的要求! )
  • 使用先前由 GCA 提供的 Workaround 作法 Bypass 永遠信任該憑證 ( 註: 只能用這招了 )

問題處理至今，發生的原因已經水落石出了，只是很可惜還是回到原點，只能用 GCA 提供的 Workaround 作法 Bypass 永遠信任該憑證!

透過有力消息來源得知，GCA 明年會針對這個問題做出因應措施，到時應該能夠解決吧？！只能等等看了…

----------

2011-03-07 更新

前幾天我又再詢問 GCA 關於此問題的進度，今天收到 GCA 客服中心的正式回函如下：
註：看來離問題解決的日子不遠了！ ^_^

為利於推動安全電子郵件及安全網站連線等應用，行政院研考會已提報「政府機關公開金鑰基礎建設憑證及憑證廢止清冊格式剖繪」1.5版之修訂，並於99年5月25日行政機關電子憑證推行小組第17次委員會議審查通過，此次的憑證廢止清冊格式剖繪的修訂主要是允許GPKI各CA將憑證廢止清冊(CRL)的序號縮短為4 Bytes，以因應微軟Windows平台之相關軟體無法處理序號長度超過4 Bytes之CRL的困擾。

由於有非常多的電子化政府應用系統皆會使用GPKI各憑證管理中心(CA)之CRL，因此不能貿然改變CRL格式，必須確定CRL格式的修改不致造成應用系統的相容性問題後，才可實施CRL改版。目前行政院研考會已完成CRL改版之大部分準備工作，行政院研考會所建置的政府憑證總管理中心 (GRCA)、政府憑證管理中心 (GCA)、組織及團體憑證管理中心 (GCA) 此 3 個 CA 預計於 100 年 5 月進行 CRL 改版，將 CRL 序號長度超過 4 Bytes，將 CRL 的序號縮短為 4 Bytes。

至於其他部會所建置的CA，例如經濟部之工商憑證管理中心(MOEACA)、內政部之內政部憑證管理中心(MOICA)等，則由其建置機關另行決定實施CRL改版的日期。

----------

本篇文章會持續更新，直到問題解決為止。

待續......

相關連結

留言評論