第二便宜的程式碼簽署

USD $75/year
https://author.tucows.com

如何用自簽憑證測試 Tomcat / IIS SSL

首先是製作自簽憑證，最大眾化的工具是 Java keytool，指令如下（所有藍字的部份都可以依個別情況修改）：

keytool -genkeypair -alias a -keystore store.pfx -storetype pkcs12 -keyalg RSA -dname "CN=www.xyz.com,OU=Unit,O=Organization,L=City,S=State,C=US" -keypass password -storepass password

接著暫時先看 Tomcat 6.x，假設上述產出的 store.pfx 放在 conf 目錄下，再來是在 server.xml 設定以下段落：

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"
           maxThreads="150" scheme="https" secure="true"
           keystoreFile="conf/store.pfx"
           keystoreType="pkcs12" keystorePass="password"
           truststoreFile="conf/store.pfx"
           truststoreType="pkcs12" truststorePass="password"
           clientAuth="false" sslProtocol="TLS" />

在用 IE 測試前，網際網路選項－＞內容－＞憑證－＞受信任的根憑證授權單位－＞匯入 store.pfx，接著開 Tomcat https 的網頁即可。

至於 IIS 7.5 則比較簡單，先在 IIS 管理員匯入伺服器憑證，當然還是 store.pfx，「允許匯出此憑證」需保持勾選；然後是 SSL 設定－＞繫結即可。

[2013/08/15 補充]

1. 在 store 只有一個 key 的情況下，也就是上例，別名（alias）可有可無。
2. CN= 的內容必須與提供外界訪問的網域名稱完全相符，在本機測試時，當然也可以是電腦名稱或是 localhost。
3. -storetype pkcs12 如果省略的話，會是另一種 keytool 預設的格式，IIS 可能不支援，Tomcat 應該會支援，Jetty 只支援這種，不接受 pkcs12。
4. keytool 預設格式的 store 即使附檔名一樣為 pfx，還是不能在 IE 匯入憑證，但我們可以用 keytool -exportcert 輕易地抽出憑證（不含金鑰）到另一個檔案，再匯入 IE。

Tomcat Connector and IIS 7.5

為了想在 IIS 環境下也能執行 Java Servlet，除了 JDK 與 Servlet Container 本身（我用的是 Tomcat）以外，在 IIS 也要部署一個 ISAPI filter。依官網（http://tomcat.apache.org/connectors-doc/reference/iis.html）的說明，雖然很詳盡了，但由於 IIS 變化太快的關係，到了 7.5 就不容易通，或者變成下載而非執行。以下是幾項特別值得注意的：

• 修改 Registry 通常是能免則免，所以我選擇編輯一個 isapi_redirect.properties 放在 isapi_redirect.dll 同一目錄下，對此目錄賦予 IUSR 以及 IIS_IUSRS 讀取、執行、列出資料夾內容等權限。
• 對於放 workers.properties 與 uriworkermap.properties 的目錄，賦予 IIS_IUSRS 讀取權限。
• 對於放 log 的目錄，賦予 IIS_IUSRS 讀取、寫入權限。
• 官網說明提到 isapi_redirect.dll 所在要設為虛擬目錄這件事不必做，但在 IIS 管理要新增「處理常式對應」，路徑是「/jakarta/isapi_redirect.dll」，執行檔當然是 isapi_redirect.dll 實際所在的完整路徑。另外，要對此「編輯功能權限」，勾選「執行」。

一般使用者權限即可安裝執行的 ActiveX

過去在網頁上部署 ActiveX，都需要電腦使用者具有管理權限才能安裝執行，但據說在 Vista 以後，就鬆綁到一般使用者權限即可。這對於我許多「MIS 管很嚴」的客戶來說，似乎是個蠻不錯（還是剛好相反？）的消息。做為一個 .NET based ActiveX 元件提供者，測試起來的確如此，但其中的小細節還有點多：

1. 元件一定要經過簽署，而且這與封裝簽署是兩回事。
2. 如果有被依賴的元件一同部署，不能放到系統目錄。
3. 封裝資訊指定部署範圍為「使用者」。
4. [.NET based ActiveX] 不能在封裝內的批次檔呼叫 RegAsm 註冊，要把寫入的所有機碼整理成一個檔案，由批次檔的命令去匯入。
5. [.NET based ActiveX, Optional] 要請使用者事先加入「信任的網站」，或對「網際網路」安全性區域修改以下兩項：「允許不提示就執行從未使用過的 ActiveX 控制項」為「啟用」、「僅允許認可的網域使用 ActiveX 而不提示」為「停用」。
6. [Optional] 若能在事前讓簽署元件的憑證位於「受信任的發行者」存放區，且上層憑證皆位於「中繼憑證授權單位」或「受信任的根憑證授權單位」，只要瀏覽器視該網站屬於網際網路（不需加入信任的網站），且安全性設定保持在預設值，元件就能不經提示直接下載安裝。

如果是一個傳統 ActiveX，只要滿足前三點即可。如果是 .NET based ActiveX 又沒做到第五點的話，安裝後的第一次執行會出現一個惱人的資訊列提示，大意是說「這個網站想要執行來自 '無法使用' 的 '控制項名稱無法使用'」，真是亂搞！如果使用者教得好，他願意相信這沒問題的話，倒是無妨。當然，這些雜事（第六點除外）也可以一起併到第四點的機碼匯入，不過安裝完之後還得提醒使用者重啟瀏覽器，如果只是對網頁重新整理的話，那個惱人的資訊列提示還是會出現。

[2013/08/09 補充]
以上第五、六點要多做的事，其實源自於第四點整理的機碼不足。後來找到一個簡單的方法：

1. 同上
2. 同上
3. 同上
4. RegAsm /regfile:a.reg 將元件的註冊指令先匯出
5. 修改 a.reg 的內容，指向 HKCR 的改成 HKCU
6. RegAsm import a.reg

這些步驟可以自動化，而且在 Windows 7, 8, 8.1 測試都沒問題。繁瑣的內容就請容許我保留給公司內訓了。

[2014/10/22 補充]
在 Windows Server 2012 摸索的經驗：

1. 在伺服器上的瀏覽器限制較嚴格，如果能將網站列入「受信任」區域會好很多。
2. 預設的 Administrator 首次開啟有 ActiveX 的網頁就是不會提示下載，當然也真的沒有下載。必須另外新增使用者，事後要不要將此人加入管理者群組都可以，反正後續的提示下載安裝 ActiveX 都正常了。