今天是學習JavaWeb的第二天，我們來了解什麼呢？就瞭解一下Tomcat中配置數字證書的相關內容，但是在說這部分內容的時候，我們貌似得先說一下數字證書的相關概念，那說到數字證書的時候我們還得了解一些密碼學的相關知識，這就是連鎖反應嗎？好吧不多說了，先來看一下密碼學中關於網路中資料傳輸的知識。

首先來了解一下網路上傳輸資料的加密方式：

第一種是對稱加密：就是加密資料的密碼和解密資料的密碼是相同的。這種方式的優點就是簡單，最大的缺點就是不安全，因為加密的密碼和解密的密碼是相同的，那麼加密的人就必須將密碼告訴解密的人，在這個過程中就存在不安全了，怎麼告訴都不安全，打電話怕人偷聽，寫信怕被人攔截。。。而且只要拿到密碼就可以進行解密資料，這種方式也是不安全的。

第二種是非對稱加密：就是加密資料的密碼和解密資料的密碼是不相同的，原理就是產生一對公鑰和私鑰，公鑰加密的資料只能私鑰解，私鑰加密的資料只能公鑰解，所以當拿到公鑰加密的資料，只能用私鑰解，公鑰是解不開的。

下面我就來通過一個例子來說明一下這個過程：

角色：接收者，傳送者，攔截者

名詞：CA機構，數字證書，數字簽名

下面的就通過這張圖來解釋一下(這張圖花了我一個上午的時間，眼睛都看花了，一定要保證我的版權呀！)：

下面就來模擬集中情況來說明一下：

第一種情況：接收者會生成一對公鑰和私鑰，並且將自己的公鑰傳送給傳送者，然後傳送者用這個公鑰將需要傳送的資料進行加密，然後再將加密之後資料傳送給接收者，這時候接收者只需要用私鑰進行解密就可以得到傳送者的資料了，在傳輸的過程中即使有攔截者拿到了傳送者傳送的資料以及接收者的公鑰，他仍然不能得到原始內容的，因為只能用私鑰進行解密，而私鑰只有接收者有。如圖中的流程：

1  ->  2  ->  3  ->  4  ->  5

第二種情況：對於第一種情況，想想就是天衣無縫了嗎？肯定不可能的了，現在有這種情況，有一個hacker,他攔截到接收者傳送給傳送者的公鑰，然後自己生成一對公鑰和私鑰，然後他把自己的公鑰傳送給傳送者，當傳送者拿到這個公鑰的時候(實際上他以為這還是接收者傳送給他的公鑰)，用這個公鑰進行加密，然後傳送給接收者，這時候hacker再次進行攔截，然後hacker攔截到資料後，就用自己的私鑰進行解密，就得到了原始資料，而接收者得到內容之後解密是失敗的，因為傳送者傳送的資料是用hacker的公鑰進行加密的。如圖中的流程：

1  ->  2(6  ->  7)  ->  3  ->  4(8  ->  9  ->  10)  ->  5

第三種情況：對於第二種情況的話，難道我們也就沒有辦法了嗎？難道我們的資訊只能無辜的被hacker進行讀取嗎？當然，道高一尺，魔高一丈，其實解決上面的問題的根本方法就是要讓傳送者相信他接收到的公鑰是接收者傳送的，而不是hacker傳送的公鑰。這個解決辦法就是有一箇中間的擔保人，擔保這個公鑰是接收者的，同時接收者需要事前找到這個擔保人說明一下。這時候就出現了一個機構：CA。這裡的CA就是上面說到的擔保人，這個機構一般是由政府機構管理的。接收者產生一對公鑰和私鑰，然後拿著公鑰到CA機構認證說明一下，同時CA會頒發一份數字證書給接收者，其實這數字證書就是有CA認證之後的公鑰。然後接收者就會將這份數字證書傳送給傳送者，當傳送者拿到這份數字證書的時候，會先到CA機構去認證一下，確定公鑰是不是接收者傳送的。然後在用數字證書進行資料加密，傳送給接收者。如圖中的流程：

1  ->  11  ->  12  ->  13  ->  14  ->  5

第四種情況：對於第三種情況，難道hacker就沒辦法了嗎？說到這裡可能有人會說，hacker可以生成一對公鑰和私鑰，然後到CA機構認證拿到數字證書，然後再攔截。這裡就要說說這個CA機構了，這個機構是由政府管理的，不是什麼人什麼機構想認證就能認證的，一般是銀行，商業性的機構才有權認證，同時認證的時候也不是隨隨便便的，需要提供很多的資訊的。這樣一說你認為hacker有權利申請了嗎？他敢申請嗎？，所以這種方法就不行了。同時也說明了一點就是數字證書這東東可以防止hakcer攔截資訊進而解密資訊。但是hacker不解密資訊，但是他仍然可以幹壞事，他可以篡改資訊。如下情景：hacker攔截了接收者傳送給傳送者的數字證書，然後在攔截髮送者使用數字證書加密的資料，這時候不是為了解密，也解不了密，而是將這些資訊儲存或者丟棄，然後使用擷取到的數字證書加密一段自己想傳送給接收者的資料，然後傳送給接收者，這時候，接收者收到的加密資料其實是hacker的，而不是傳送者傳送的，如圖中的流程：

1  ->  11  ->  12(15)  ->  13  ->  14(16)  ->  5

第五種情況：對於第四種情況，難道我們有沒有辦法了嗎？我們的資訊就任hacker進行篡改，這肯定是不可能的，上有政策，下有對策。那我們該怎麼辦呢？解決的思路就是接收者要驗證資料在傳輸的過程中沒有被篡改過。那麼這裡又要說到一種技術：數字簽名操作步驟：首先發送者也會生成一對公鑰和私鑰，同時向CA機構得到一份數字證書，同時這時候傳送者將要傳送的資料使用私鑰進行加密A，同時使用私鑰對資料的資料指紋(MD5)進行加密(數字簽名)B，然後將A和B以及傳送者的數字證書一起傳送給接收者，接收者拿到資料之後：

第一步：然後向CA機構驗證數字證書是不是傳送者的，是的話，就用數字證書解密資料指紋(MD5)資料
第二步：使用數字證書解密傳送者的資料
第三步：將第二步中得到的資料獲取一下指紋，和第一步中獲取到的資料指紋相比較，如果相等就表示傳送內容沒有被篡改，否則就被篡改了。

這樣就可以防止資訊傳送的過程中防止被篡改了。

以上是介紹完了網路中傳輸資料中設計到的密碼學的知識，下面就來介紹一下使用Tomcat來進行數字證書的配置：

首先我們使用java自帶的一個命令生成一個金鑰庫keystore檔案：

keytool -genkeypair -alias "tomcat" -keyalg "RSA"

這裡需要給金鑰庫配置密碼，然後是姓氏，這裡面的這個姓氏就是給哪個網站配置數字證書，我們這裡是localhost，這個資訊一定要填寫正確，不然沒有效果的，其他的資訊我們這裡只做演示，所以可以不填的，按回車，最後輸入y,這時候就會在你的本機使用者目錄中生成一個.keystore檔案。這個就是金鑰庫檔案了。

金鑰庫檔案生成好了，接下來我們就來配置Tomcat檔案了，找到server.xml檔案，開啟：

這時候我們將剛剛生成的.keystore放到conf資料夾下面，配置server.xml檔案內容如上圖所示，密碼就是剛剛生成.keystore檔案時敲入的密碼。儲存server.xml檔案，然後重啟tomcat

使用IE瀏覽器(Chrome看不到效果的)，在位址列中輸入：

https://localhost:8443

這裡一定要使用https協議了，因為是加密訪問的，還有這裡要使用8443埠了，因為我們要訪問我們的數字證書的聯結器，在瀏覽器中看到：

這時候IE瀏覽器會提示我們這個數字證書不是由CA機構頒發的，不可信(因為IE瀏覽器中集成了這種數字證書的檢查機制)，我們點選繼續瀏覽此網站：

這時候就可以連線到了數字證書聯結器，同時可以看到位址列的右邊多了一個圖示：說是證書錯誤，我們點選這個圖示，他再次彈出一個提示，說這個證書不可靠，我們不管他了，點選檢視證書：

這時候他還是提示我們這個證書不安全，看到頒發者是localhost了，這時候我們點選安裝證書，安裝完成之後，到此為止我們就為我們自己的localhost網站安裝了我們自己的localhost的數字證書了。這樣使用者在訪問localhost網站的時候，使用者提交的資料就會使用我們安裝好的數字證書進行加密了。

總結：上面就大體上說了一下網路中傳輸資料中的相關加密的知識以及怎麼使用tomcat配置一個數字證書。其實這些內容我們日常生活中都是會接觸到的，最明顯的例子就是網銀了。你在訪問銀行網站的時候，他會提示你安裝一下數字證書，這個就說明：該銀行生成了一對公鑰和私鑰，然後到CA機構去認證一下得到了一份數字證書，然後在將這份數字證書配置到該網站上面即可。