通向架构师的道路（第二天）之apache tomcat https应用
一、總結(jié)前一天的學(xué)習(xí)
在前一天的學(xué)習(xí)中我們知道、了解并掌握了Web Server結(jié)合App Server是怎么樣的一種架構(gòu)，并且親手通過Apache的Http Server與Tomcat6進(jìn)行了整合的實(shí)驗(yàn)。
這樣的架構(gòu)的好處在于：
ü?? 減輕App Server端的壓力，用Web Server來分壓，即Web Server只負(fù)責(zé)處理靜態(tài)HTML內(nèi)容，而App Server專職負(fù)責(zé)處理Java請求，這對系統(tǒng)的performance是一個極大的提升。
ü?? 安全，Web Server端沒有任何Java源代碼包括編譯后的東西，對Internet開放的只有Web Server，因此黑客就算通過80端口攻入了我們的Web Server，他能得到什么？除了靜態(tài)HTML內(nèi)容，任何邏輯，口令他都得不到，為什么？喏。。。因?yàn)槲覀兊腁pp Server“躲”在Web Server的屁股后面呢。
需要注意的地方：
ü?? 如果以這樣的架構(gòu)出現(xiàn)，你的J2EE 工程，必須在web.xml里把那些個<servlet-mapping>劃分清楚，比如說：
我們可以知道*.do, *.action, *.jsp是屬于JAVA需要解析的東西對吧！
但是，如果你的servlet寫成這樣
/abc
/123
/def
那么當(dāng)我們在作映射時(shí)，需要把/abc, /123, /def分別寫成一行行的JKMount語句，是不是。。。OK，假設(shè)我們這個工程有100個servlet（這個算少的哦），你該不會在httpd.conf文件中給我寫這樣的無聊的東西100行吧？
所以，我們在規(guī)劃我們的servlet時(shí)需要有矩可循，即pattern，因此我才一直強(qiáng)調(diào)，大家在servlet命名時(shí)必須統(tǒng)一成：
/servlet/myServletabc
這樣，我在做這個Web Server到App Server的Mapping時(shí)，是不是只要一句：JkMount /servlet/* ajp13就可以搞定啦？
ü?? 同樣的架構(gòu)有不同的變種：
2? IIS+Tomcat
因?yàn)槲④浀腎IS本身就是一個Web Server，因此通過IIS和Tomcat的一個插件叫”isapi”的也可以作到這樣的架構(gòu)，但是我強(qiáng)烈不推薦，因?yàn)镴AVA源于Unix系統(tǒng)，歸于Unix系統(tǒng)，Unix可是不認(rèn)什么IIS的，一定請一定用Apache，你是JAVA不是多奶（dot net）。
2? Apache+Weblogic
2? IBM HttpServer(Apache的一個變種)+IBM WAS6.x/WAS7.X
2? Tomcat集群
Apache掛N多個tomcat，由tomcat1…tomcat2…tomcat3…等組成
2? Weblogic集群
Apache掛N多個weblogic，由weblogic1…weblogic2…weblogic3…等組成
2? WASND（IBMWebsphere App Server Network Deployment）
IBM HttpServer掛N多個WAS，由WAS1…WAS2…WAS3…等組成
二、HTTPS
2.1 HTTPS介紹
先來看HTTPS的概念
我們一般的http走的是80端口，而https走的是443端口，有什么不一樣的地方嗎？
很簡單，我們拿個telnet命令來作個實(shí)驗(yàn)：
telnet127.0.0.1 80，直接就登進(jìn)了80端口（如果你機(jī)器上的Apache開放的話），這樣好極了，所有的http中的get, put, post全部可以被我們截獲，你的上網(wǎng)帳號，你提交的表單信息全部被別人攔截，就算你對一些信息加了密，對于黑客來說，這些加密被解密只是時(shí)間問題，而且一般黑客可以利用云計(jì)算，群集計(jì)算對你的加密可以進(jìn)行“硬殺傷”，即窮舉算法，利用超大規(guī)模集群解密的你的算法會很快，電影里的幾十秒解開一個128位的加密不是神話，是真的！！！
因此，我們要讓黑客一開始就攻不進(jìn)來，連門都進(jìn)不來，何談拿到我里面的東西，對不對？
現(xiàn)在我們把我的http通道，變成了https，同時(shí)關(guān)閉80端口，因此用用戶要訪問必須經(jīng)過443端口。好了，我們再來用:
telnet localhost 443
你連telnet都進(jìn)不進(jìn)去，因此，你就無法再獲取http通道內(nèi)傳輸?shù)臇|西了。因此黑客要進(jìn)入你的網(wǎng)站先要突破這個https，而https使用的是RSA非對稱128位加密，如果是安全交易類甚至?xí)褂肦SA 1024位加密算法，除非是世界上最高明的黑客才能突破我們的防線。
2.2 HTTPS的構(gòu)成
要構(gòu)成HTTPS，我們需要有一張“根證書”，一張“服務(wù)器認(rèn)證”才能做到一般的https，HTTPS還分成“雙向認(rèn)證”，在雙向認(rèn)證的結(jié)構(gòu)中我們需要3張證書即“根證書”，“服務(wù)器認(rèn)證”，“客戶端認(rèn)證”。為什么需要這么多證書？嘿嘿，下面我們來看HTTPS是怎么構(gòu)成這個“信任關(guān)系鏈”的。
ü?? 證書我們稱為CA；
ü?? 根證書叫Root CA；
上述這個圖什么意思？
首先，RootCA是全球的根，這個“樹”的根是全球任何IE、FireFox、Safari里的證書庫里都有這個RootCA的，因?yàn)樗鼈兪菣?quán)威，所以全球的電子證書拿它們做“根”，這些證書比較具有代表性的是：
ü?? Verisign
ü?? RSA
這兩家公司是世界上所有加密算法的“鼻祖”，因此被拜為全球所信任，我們可以在我們的IE中看到這些“根”。
其此，全球的計(jì)算器客戶默認(rèn)在裝完系統(tǒng)后，都會帶有這些ROOT CA，因此“由ROOT CA簽出來的服務(wù)器證書將自動被客戶端所信任”。
所以，這個信任關(guān)系，就此建立。
在HTTPS是SSL的一種，它們間是如何進(jìn)行加密傳輸?shù)哪?#xff0c;就是這個“信任關(guān)系”，先建立起信任關(guān)系，然后再開始數(shù)據(jù)傳輸，在加密的世界中“建立信任”就需要用到至少2張證書，即ROOT CA， SERVER CA，我們把這個信任建立的過程稱為“Hands Shake”，握手協(xié)議。
前面說到了，這個握手分單向和雙向，包括上述這個圖就是一個單向握手，什么叫單向，什么叫雙向呢？我們下面來講解：
ü?? 單向握手信任
我們又稱它為“包二奶協(xié)議”，大家想一下，貪官包二奶和二奶說“你跟著我，我每月給你1萬塊”，他說的這個話，能不能寫下來？ 能嗎？ 當(dāng)然不能，寫下來還得了，將來二奶一不爽把這份白紙黑字的東西交到中紀(jì)委還不把這爛貨給雙規(guī)了哈？
所以，二奶單向里信任貪官，這就是二奶協(xié)議，即客戶端認(rèn)為我訪問的這臺服務(wù)器“是安全的”，因此客戶端可以向服務(wù)器發(fā)送和提交任何東西。
ü?? 雙向握手信任
我們又稱它為“君子協(xié)定”，呵呵，從這個詞表面上來看就知道這個協(xié)議有多牢靠了，首先，它是寫在字面上的，其次，雙方都簽署協(xié)議這個信任關(guān)系怎么樣啊？ 非常牢靠！
即客戶端信任服務(wù)器，因此客戶端可以向服務(wù)器發(fā)送和提交任何東西。同時(shí)，服務(wù)器也信任客戶端，允許該客戶端向我發(fā)送和提交東西。
客戶端單向信任服務(wù)器很簡單，只要這個服務(wù)器是我客戶端信任的頂級根簽發(fā)出來的證書就行，而服務(wù)器如何信任客戶端呢？記住下面三句話：
首先，你這個客戶端到我這邊來登記一下；
其次，我給你簽一張證書，你帶回家裝在你的IE里；
最后，每次訪問時(shí)因?yàn)槟愕?/span>IE里裝著我服務(wù)器簽出的證書，所以你是我的會員，所以我信任你；
2.3?證書與如何生成證書的基本概念
通過上面的概念，我們知道了，如果建立起這個HTTPS的環(huán)境我們需要至少一張服務(wù)器證書，對不對？而且這張服務(wù)器證書是需要由客戶端信任的“ROOT”級機(jī)構(gòu)所簽發(fā)出來的。
所以一般生成證書由以下幾個步驟構(gòu)成：
1.?????? 生成一對不對稱密鑰，即公鑰public key和私鑰 private key
2.?????? 用密鑰產(chǎn)生請求，同時(shí)把我的請求交給ROOT機(jī)構(gòu)
3.?????? ROOT機(jī)構(gòu)對我提交的請求進(jìn)行“簽名”Sign
這個被簽完名后的“請求”就稱為證書。
上面多出來了密鑰，公鑰，私鑰三個名詞，下面來做解釋。
先來看一個真理：
1）密鑰，密鑰為一對，即一把公鑰，一把私鑰
2）一把私鑰可以對應(yīng)多把公鑰，而這些公鑰只可能來源于一把私鑰
3）公鑰加密，私鑰解密
大家想一下，公鑰加密，這是“公”就是人人有這把KEY，都可以用來加密，但是能打開我這扇門的因該只有一個人是吧？這就是為什么說“私鑰”解密。
倒過來
私鑰“加密”（被稱為簽名），公鑰“解密”（被稱為認(rèn)證）
把上面這個“真理”倒過來，呵呵，好玩了，因?yàn)閜ublic key只能用來加密而解密必須是private key，因此公鑰是不能加密的，公鑰也不能用來解密，那么它們該怎么做？
HP公司是賣打印機(jī)的，它有100個代理，都為它銷售打印機(jī)。
客戶來到了某個代理公司，問：你憑什么說你是HP的代理
代理公司說：請看，這是HP公司給我證書
客戶問：你的證書不能偽造嗎？
代理公司答：請看，下面有一個防偽條形碼
于是，客戶把這個防偽條形碼用手機(jī)拍下來，來到HP公司說：這是不是你們的代理？
HP公司說：你等一下！?隨后HP公司拿出以前給這家代理公司的公鑰，對這個簽名做一個“解密”（被稱為雜湊算法），也算出來一個防偽條形碼，然后拿這個防偽條形碼和客戶帶來的防偽條形碼一比較，完全一致，所以HP和客戶說：您可以完全相信這家公司，這家公司是我代理的。
這邊這個防偽條形碼就是代理公司用HP在頒發(fā)證書時(shí)給它時(shí)用HP的私鑰的“簽名”；
HP公司用為當(dāng)初給代理商發(fā)放證書時(shí)同時(shí)生成的密鑰對里的公鑰對這個簽個名做一個雜湊算法，然后拿算出來的防偽條形碼再和客戶帶來的這個防偽條形碼比對的這個過程被稱為“認(rèn)證”；
一起來看看證書里的防偽條形碼吧
我們把它稱為電子“指紋”，一般用的是SHA或者是MD5算法，因?yàn)镸D5和SHA是不可逆唯一性算法，所以把它比喻成“指紋”再恰當(dāng)不過了。
2.4?實(shí)際開發(fā)實(shí)驗(yàn)中如何產(chǎn)生證書
實(shí)際產(chǎn)生證書時(shí)，我們需要生成請求，但不是說我們把請求交給Verisign或者一些信息機(jī)構(gòu)，它們就幫我們簽的，這是要收費(fèi)的，一般簽個名：50-500美金不等，有時(shí)還分為每年必須去簽一次，要不然就會失效。
所以我們在實(shí)際開發(fā)環(huán)境中，為了做實(shí)驗(yàn)或者是搭建模擬環(huán)境，不可能會去花錢買個證書的，有時(shí)我們環(huán)境要搭建幾套，怎么辦？這錢花的沒有明堂的。
所以，在實(shí)際開發(fā)環(huán)境中，我們自己來模擬這個ROOTCA，然后用自己模擬出來的ROOTCA去簽我們服務(wù)器的證書，這個過程就被稱為“自簽”。
2.5?使用OpenSSL來簽證書
OpenSSL就是這么一個自簽，加密的命令行工具，它是從UNIX下分離出來的一個項(xiàng)目，但也有FOR WINDOWS平臺的，比如說我給你們用的這個OPENSSL，就是For WIN的，但是由于它是從UNIX/Linux下產(chǎn)生的，因此它內(nèi)部的配置還是用的是LINUX/UNIX的盤符與路徑，需要手動去校正，當(dāng)然我已經(jīng)做好了校正，因此直接打了個壓縮包放在了FTP上，大家拿下來后解壓后就可以直接用了。
如果你們是自己從網(wǎng)上官方網(wǎng)站下載的OPENSSL需要手動去改它的盤符和路徑，要不然是用不起來的。
ü?? 設(shè)置環(huán)境變量
把c:\openssl\bin\openssl.cnf設(shè)成OPENSSL_CONF這樣的一個變量，同時(shí)把c:\openssl\bin目錄加到你的path里去（根據(jù)你們自己的解壓后的openssl的實(shí)際路徑）。
ü?? 生成根證書所用的密鑰
提示輸入密碼我們使用：aaaaaa
再次輸入確認(rèn)密碼
（密鑰，由其是private key是由口令保護(hù)的）
去除CA密鑰的口令
為什么我們要把好好的口令保護(hù)給去除呢？這邊不是去除而是代表這個證書在被應(yīng)用程序啟動時(shí)不需要顯示的提示用戶輸入口令，要不然我們會出現(xiàn)下面這種情況：
在啟動HTTPS協(xié)議的服務(wù)器時(shí)，一般我們點(diǎn)一下service->apache2.x啟動，就啟動了，但如果這個https所帶的證書是沒有經(jīng)過上述這道手續(xù)后處理的話，這個服務(wù)在啟動時(shí)會失敗，而需要切換成手動命令行啟動，就是黑屏！在黑屏狀態(tài)下，apache2.x服務(wù)器啟動時(shí)會提示你要求：輸入口令，這個太麻煩了，一般啟動服務(wù)器服務(wù)的一定是超級管理員，因此一般情況下沒必要在啟動相關(guān)服務(wù)時(shí)再輸入一遍口令了。
ü?? 生成CA即ROOT CA證書并自簽
網(wǎng)上有很多說法，說是先產(chǎn)生CA的Request請求，再用ca.key去自簽，我給大家介紹一條一步到位的產(chǎn)生ca ROOT證書的命令，為了安全，我們在最后加上“-configC:\openssl\bin\openssl.cnf”，以使openssl工具可以找到相應(yīng)的config文件（有些系統(tǒng)在指定了OPENSSL_CONF環(huán)境變量后一般就不需要在命令行里去手工指定這個-config變量了）。
由于我們產(chǎn)生的證書為:X509格式，因此需要按照X509格式填入相關(guān)的值。
2? AU-國家家的縮寫，如：CHINA=CN，美國=USA，英國=UK，日本=JP
2? State or Province Name-省/洲的縮寫或者是全稱，如：上海=SH
2? Locality Name-城市的全稱或者是縮寫，如：上海=SH
2? Organization Name-公司名，如：Cognizant
2? Common Name-要安裝這臺證書的主機(jī)名，證書是和主機(jī)名綁定的，如果證書里的主機(jī)名和你實(shí)際的主機(jī)名不符，這張證書就是非法的證書。
我們不能夠填IP，一定一定要填主機(jī)名即域名www.xxx.com這樣的東西，比如說我填的是shnlap93，但我的主機(jī)怎么知道shnlap93是指:10.225.106.35或者說是指localhost這臺機(jī)器呢？
打開C:\Windows\System32\drivers\etc\hosts這個文件，如下：
| localhost shnlap93 10.225.106.35 shnlap93 |
看到了吧？所以當(dāng)我們使用pint shnlap93時(shí)，它是不是就可以知道shnlap93=10.225.106.35啦？
EmailAddress-郵件地址，愛填不填，可以跳過，反正我們是“自簽”。
Look，我們的CA證書生成了，可以雙擊這張證書，查看信息后關(guān)閉它。
目前這張ROOT 證書，只是個自簽的產(chǎn)品，因?yàn)槭亲院?#xff0c;一般其它客戶端的IE里因此是不會帶有這張根證書的。
要其實(shí)客戶端也能信任這張根證書，我們必須怎么辦？
將它安裝到我們的IE的信任域里。
ü?? 將ROOT CA導(dǎo)入客戶端的根級信任域，有多少臺客戶端，每個客戶端都要導(dǎo)一邊這個證書！
所以說如果我們擁有世界級的根證書該多好啊，電腦上默認(rèn)就帶有我們的證書，因此知道這幫世界級的根證書機(jī)構(gòu)為什么能掙錢了吧？50-500美金簽張證書，幾秒鐘的事，CALL！！！
點(diǎn)[導(dǎo)入]按鈕
下一步，下一步，此時(shí)會有一個彈出框，選“yes（是）”完成導(dǎo)入。
再來打開我們的ca.crt文件
發(fā)現(xiàn)了沒有，這張證書是有效的證書了，所以在“證書信息”前原有的一個紅叉叉，消失了。
ü?? 生成Web服務(wù)器端證書密鑰
我們的root證書有了，現(xiàn)在可以生成Web服務(wù)器端的證書了，并且用root ca去簽名
先生成密鑰，密碼6個a
去除密碼（提示：enter pass phrase for server.key時(shí)輸入剛才生成密鑰時(shí)的密碼即6個a。
ü?? 生成Web服務(wù)器端證書的簽名請求
生成服務(wù)器端證書請求時(shí)需要輸入server端key的口令，我們?yōu)榱朔奖?#xff0c;也用6個a。
ü?? 用Root CA去對Web服務(wù)器的證書請求即csr(certificate request)進(jìn)行簽名認(rèn)證
輸入y并回車
此時(shí)它會提示：
1 out of 1certificate requests certified, commit? [y/n]，再 輸入y并回車
Web服務(wù)器的server.crt證書生成完畢。
注：
如果在操作時(shí)有任何錯，必須連同生成的.key,.csr, .crt文件全部刪除重頭來一遍
我們來看看，這個server.crt文件，雙擊它。
首先，我們看到該證書的“證書信息”前沒有紅色的大叉，然后是證書信息正是我們剛才輸入的內(nèi)容，為什么沒有大叉？
因?yàn)槲覀兊?/span>RootCA根證書裝在我們IE的根級信任域里，又因?yàn)槲覀兊目蛻舳诵湃挝覀兊?/span>RootCA，因此當(dāng)我們的客戶端打開由RootCA簽出來的server.crt時(shí)，這根“信任鏈”被建立了起來，所以客戶端自動單向信任我們的server.crt，對不對？
下面我們來做一個實(shí)驗(yàn)，把我們的Root CA從我們的根級信任域中刪除。
選中這個shnlap93的根級證書，點(diǎn)[刪除]，會彈出兩次確認(rèn)框，選“yes”確認(rèn)刪除掉它。
關(guān)閉IE，然后我們再次雙擊我們的server.crt文件，來查看證書內(nèi)容。
我們看到了什么？“不能驗(yàn)證該證書。
重新導(dǎo)入我們的Root CA至IE的根級信任域（見將ROOT CA導(dǎo)入客戶端的根級信任域）。
再次打開server.crt查看證書內(nèi)容。
一切回復(fù)正常了。
2.6?為Apache HttpServer布署https協(xié)議
ü?? 用文本編輯器打開httpd.conf文件，找到如下這一行
| #Include conf/extra/httpd-ssl.conf |
這行默認(rèn)是被注釋掉的，因此請把它放開，修改成如下
| Include conf/extra/httpd-ssl.conf |
ü?? 打開D:\tools\httpd\conf\extra\里的httpd-ssl.conf文件
在開頭處添加如下這一行語句
| # # This is the Apache server configuration file providing SSL support. # It contains the configuration directives to instruct the server how to # serve pages over an https connection. For detailing information about these # directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html> # # Do NOT simply read the instructions in here without understanding # what they do.? They're here only as hints or reminders.? If you are unsure # consult the online docs. You have been warned.? # LoadModule ssl_module modules/mod_ssl.so |
然后找到下面這一行
| SSLCertificateFile "D:/tools/httpd/ |
把它改成：
| SSLCertificateFile "D:/tools/httpd/cert/server.crt" |
再找到下面這一行
| SSLCertificateKeyFile "D:/tools/httpd/ |
把它改成
| SSLCertificateKeyFile "D:/tools/httpd/cert/server.key" |
然后把我們在我們的Apache HttpServer的安裝目錄下手工建一個目錄叫cert的目錄，并把我們在前面生成的server.crt與server.key文件拷入d:\tools\httpd\cert目錄內(nèi)。
在httpd.conf文件中搜索“ServerName”
搜到下面這樣的一句
| ServerName 10.225.101.35:80 |
把它改成你的主機(jī)名
| ServerName shnlap93:80 |
此處的shnlap93是你的主機(jī)名
再繼續(xù)在httpd.conf文件中搜索“VirtualHost *”
搜到下面這一句
| <VirtualHost *> |
把它改成
| <VirtualHost shnlap93:80> |
在D:\tools\httpd\conf\extra\httpd-ssl.conf文件中查找
搜“VirtualHost _default_:443”
然后把位于< VirtualHost _default_:443>段內(nèi)的頭三行改成如下格式
2? 確保你的http的發(fā)布目錄在d:/www
2? 確保你的HTTPS的主機(jī)名為shnlap93:443(這邊的名字和生成證書里的common name必須完全一模一樣連大小寫都必須一樣)
| DocumentRoot "D:/www" ServerName shnlap93:443 ServerAdmin admin@localhost |
然后在下一個“</VirtualHost>? ”結(jié)束前，填入下面這幾行語句
| DirectoryIndex index.html index.htm index.jsp index.action JkMount /*WEB-INF ajp13 JkMount /*j_spring_security_check ajp13 JkMount /*.action ajp13 JkMount /servlet/* ajp13 JkMount /*.jsp ajp13 JkMount /*.do ajp13 JkMount /*.action ajp13 JkMount /*fckeditor/editor/filemanager/connectors/*.* ajp13 JkMount /fckeditor/editor/filemanager/connectors/* ajp13 |
在重啟我們的Apache服務(wù)前先Test Configuration一下，如果一切無誤，可以重啟了。
然后我們來實(shí)驗(yàn)一下我們的Web Server的https的效果
看到?jīng)]有，這個紅圈圈起來的地方，目前是正常的，顯示金黃色的一把鑰匙。
如果你的Root CA沒有裝入IE的根級信任域，此時(shí)你敲入https://shnlap93/cbbs時(shí)，你會被提示說“該證書不被任何”，然后讓你點(diǎn)一下“確認(rèn)”按鈕，點(diǎn)完信任后能進(jìn)入我們的Web應(yīng)用，但是，原先應(yīng)該顯示“金黃色鑰匙”的地方會顯示一個紅色的圈圈，并且當(dāng)你查看證書信息時(shí)，這個地方也會顯示“證書不受信任”，并且顯示一個紅色的大叉。
2.7?為Tomcat也布署https協(xié)議
我們的Apache HttpServer已經(jīng)走h(yuǎn)ttps協(xié)議了，不是已經(jīng)enough了嗎？NO，遠(yuǎn)遠(yuǎn)不夠，如果你沒有用到任何App Server即tomcat/weblogic/was那么我們說我們的應(yīng)用已經(jīng)走h(yuǎn)ttps協(xié)議了，但是因?yàn)槲覀兊募軜?gòu)是Web Server + App Server，因此，我們的App Server也必須走https協(xié)議。
如果只是Web Server走https協(xié)議，而App Server沒有走https協(xié)議，這就叫“假https架構(gòu)”，是一種極其偷賴和不負(fù)責(zé)任的做法。
概念同產(chǎn)生Apache的HttpServer的證書一樣，只是這邊的信任域有點(diǎn)不一樣。
Web的信任域就是你的IE里的內(nèi)容里的證書里的“根級信任域”，App Server的信任域是打不開也不能訪問這塊地方的，而且App Server的信任域格式也不是crt文件，而是.jks(javakey store的簡稱)。
下面來做一個tomcat的https布署。
原有ca.crt和ca.key繼續(xù)有用，因?yàn)镽OOT CA都是一個，而且必須一定始終是唯一的一個，對吧？
我們直接從server.jks來做起。
說JKS，這東西好玩的很，jks文件其實(shí)就是把key文件與crt文件合在一起，以java key store的格式來存儲而己。
2.8?生成Tomcat的SSL證書
為Tomcat的server所在的服務(wù)器生成一個server.jks文件
很多網(wǎng)上的資料是拿原先的server.crt文件轉(zhuǎn)成keystore文件，其實(shí)是不對的，需要單獨(dú)生成一張server.jks文件。
怎么生成證書？回顧一下上文：
1）? 生成KEY
2）? 生成證書請求
3）? 用CA簽名
下面開始使用%JAVA_HOME%\bin目錄下的keytool工具來產(chǎn)生證書
ü?? 生成JKS密鑰對，密碼使用6個a，alias代表“別名”，CN代表Common Name，必須與主機(jī)名完全一致，錯了不要怪我自己負(fù)責(zé)。
| keytool -genkey -alias shnlap93X509 -keyalg RSA -keysize 1024 -dname "CN=shnlap93, OU=insurance-dart, O=Cognizant, L=SH, S=SH, C=CN" -keypass aaaaaa -keystore shnlap93.jks -storepass aaaaaa |
ü?? 生成JSK的CSR
| keytool -certreq -alias shnlap93X509 -sigalg "MD5withRSA" -file shnlap93.csr -keypass aaaaaa -keystore shnlap93.jks -storepass aaaaaa |
此處注意：
Alias名必須和上面一致
密碼和上面一致
ü?? 使用openssl結(jié)合ca.crt與ca.key為jsk的csr來簽名認(rèn)證并產(chǎn)生jks格式的crt
| openssl x509 -req -in shnlap93.csr -out shnlap93.crt -CA ca.crt? -CAkey ca.key -days 3650 -CAcreateserial -sha1 -trustout -CA ca.crt -CAkey ca.key -days? 3650 -CAserial ca.srl -sha1 -trustout |
提示yes和no時(shí)選yes
???????? 于是，我們有了一張符合jks格式的crt證書叫shnlap93.crt文件，來查看它。
證書上沒有紅色的大叉，因?yàn)槲覀兊腞oot CA裝在我們的IE的根級信任域中，OK，下面來了，生成這個JKS，就是把crt和key合在一起，來了！
ü?? 生成符合x509格式的jks文件
1)????? 將Root CA導(dǎo)入jks信任域
| keytool -import -alias rootca -trustcacerts -file ca.crt -keystore shnlap93.jks -storepass aaaaaa |
前面我說了，jks信任域是讀不到IE的根級信任域的，因此要手動把ca.crt文件導(dǎo)入jks的信任域
1)????? 現(xiàn)在我們的shnlap93.jks文件中有兩個realm(域)，一個是：
2? 本身的csr(產(chǎn)生的簽書請求認(rèn)證的域，還沒被認(rèn)證，因?yàn)檎J(rèn)證的內(nèi)容變成了shnlap93.crt文件了是不是？)
2? 剛才步驟中導(dǎo)入的Root CA認(rèn)證域
那么客戶端信任Root CA沒有問題，但由于server端本身的信任域還只是處于“請求被簽名”的狀態(tài)，那么客戶端如何去信任這個jks文件呢？
答案就是：補(bǔ)鏈，補(bǔ)這根信任鏈！
| keytool -import -alias? shnlap93X509 -file shnlap93.crt -keystore shnlap93.jks -storepass aaaaaa |
我們不是生成過shnlap93.crt嗎？把它導(dǎo)入jks不就是能夠把原有的“正在處于請求被簽名認(rèn)證”這個狀態(tài)改成“已經(jīng)被Root CA簽名認(rèn)證” 了嗎？對吧？
所以，我們用于布署tomcat的ssl證書的jks格式的文件shnlap93.jks已經(jīng)完整了。
2.9?布署Tomcat上的Https協(xié)議
Apache HttpServer走的是443端口，Tomcat走的就是8443端口。
打開tomcat的conf目錄下的server.xml，我們來找下面這一段：
| ??? <!-- ??? <Connector executor="tomcatThreadPool" ?????????????? port="8080" protocol="HTTP/1.1" ?????????????? connectionTimeout="20000" ?????????????? redirectPort="8443" ?????????????? /> ??? --> |
默認(rèn)情況下，它是被由“<!--? -->”這樣的標(biāo)簽給注釋起來的，我們把它放開
| <!-- enable tomcat ssl --> ??? <Connector executor="tomcatThreadPool" ?????????????? port="8080" protocol="HTTP/1.1" ?????????????? connectionTimeout="20000" ?????????????? redirectPort="8443" ?????????????? clientAuth="false" sslProtocol="TLS" ?????????????? keystoreFile="d:/tomcat2/conf/shnlap93.jks" keystorePass="aaaaaa" ??? /> |
2? clientAuth=”false”
如果該值為”true”就代表要啟用雙向認(rèn)證
2? keystoreFile就是我們生成的keystore文件所在的完全路徑
2? keystorePass就是我們生成keystore時(shí)的password
重啟tomcat,輸入https://shnlap93:8080/cbbs, 可以看到登錄網(wǎng)頁,且右上方的SSL連接信息為“金黃色的鑰匙”而不是紅色大叉，那么一切就成功了。
重啟Apache，然后在ie地址欄輸入:?https://shnlap93/cbbs，用sally/abcdefg，一切成功。
注意：
當(dāng)啟用了https協(xié)議后，你在ie地址欄就不能再用localhost了，為什么？因?yàn)槲覀兊淖C書中的CN(Common Name)填入的是主機(jī)名，如果你還用:https://localhost，那么你也能正常進(jìn)入網(wǎng)址，只是多了幾步https不被信任的警告框，并且你右上角的ssl連接信息為紅色的大叉，對于這樣的https連接，如果換成是購物網(wǎng)站，你敢信任嗎？
2.10 apache https + tomcat https
2? 假https
前面說過，如果你是在Apache上啟用了https而沒有在tomcat上啟用https協(xié)議，那么我們在tomcat中布署一個servlet，含一條打印語句： System.out.println(“”+request.getScheme())，那么它將打印出來http。
2? 真https
如果我們在Apache上啟用了https通時(shí)在tomcat上也啟用了https，那么我們?nèi)绻羞@樣的一條語句：System.out.println(“”+request.getScheme())，它打印出來的將是：https。
總結(jié)
以上是生活随笔為你收集整理的通向架构师的道路（第二天）之apache tomcat https应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 通向架构师的道路（第一天）之Apache
- 下一篇： 通向架构师的道路（第四天）之Tomcat