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