apache tomcat https應用

時間 2019-12-08

原文原文鏈接

1、總結前一天的學習

在前一天的學習中咱們知道、瞭解並掌握了Web Server結合App Server是怎麼樣的一種架構，而且親手經過Apache的Http Server與Tomcat6進行了整合的實驗。html

這樣的架構的好處在於：java

ü 減輕App Server端的壓力，用Web Server來分壓，即Web Server只負責處理靜態HTML內容，而App Server專職負責處理Java請求，這對系統的performance是一個極大的提高。web

ü 安全，Web Server端沒有任何Java源代碼包括編譯後的東西，對Internet開放的只有Web Server，所以黑客就算經過80端口攻入了咱們的Web Server，他能獲得什麼？除了靜態HTML內容，任何邏輯，口令他都得不到，爲何？喏。。。由於咱們的App Server「躲」在Web Server的屁股後面呢。算法

須要注意的地方：spring

ü 若是以這樣的架構出現，你的J2EE 工程，必須在web.xml裏把那些個<servlet-mapping>劃分清楚，好比說：apache

咱們能夠知道*.do, *.action, *.jsp是屬於JAVA須要解析的東西對吧！api

可是，若是你的servlet寫成這樣tomcat

/abc安全

/123服務器

/def

那麼當咱們在做映射時，須要把/abc, /123, /def分別寫成一行行的JKMount語句，是否是。。。OK，假設咱們這個工程有100個servlet（這個算少的哦），你該不會在httpd.conf文件中給我寫這樣的無聊的東西100行吧？

因此，咱們在規劃咱們的servlet時須要有矩可循，即pattern，所以我才一直強調，你們在servlet命名時必須統一成：

/servlet/myServletabc

這樣，我在作這個Web Server到App Server的Mapping時，是否是隻要一句：JkMount /servlet/* ajp13就能夠搞定啦？

ü 一樣的架構有不一樣的變種：

² IIS+Tomcat

因爲微軟的IIS自己就是一個Web Server，所以經過IIS和Tomcat的一個插件叫」isapi」的也能夠做到這樣的架構，可是我強烈不推薦，由於JAVA源於Unix系統，歸於 Unix系統，Unix但是不認什麼IIS的，必定請必定用Apache，你是JAVA不是多奶（dot net）。

² Apache+Weblogic

² IBM HttpServer(Apache的一個變種)+IBM WAS6.x/WAS7.X

² Tomcat集羣

Apache掛N多個tomcat，由tomcat1…tomcat2…tomcat3…等組成

² Weblogic集羣

Apache掛N多個weblogic，由weblogic1…weblogic2…weblogic3…等組成

² WASND（IBMWebsphere App Server Network Deployment）

IBM HttpServer掛N多個WAS，由WAS1…WAS2…WAS3…等組成

2、HTTPS

2.1 HTTPS介紹

先來看HTTPS的概念

咱們通常的http走的是80端口，而https走的是443端口，有什麼不同的地方嗎？

很簡單，咱們拿個telnet命令來做個實驗：

telnet127.0.0.1 80，直接就登進了80端口（若是你機器上的Apache開放的話），這樣好極了，全部的http中的get, put, post所有能夠被咱們截獲，你的上網賬號，你提交的表單信息所有被別人攔截，就算你對一些信息加了密，對於黑客來講，這些加密被解密只是時間問題，並且通常黑客能夠利用雲計算，羣集計算對你的加密能夠進行「硬殺傷」，即窮舉算法，利用超大規模集羣解密的你的算法會很快，電影裏的幾十秒解開一個128位的加密不是神話，是真的！！！

所以，咱們要讓黑客一開始就攻不進來，連門都進不來，何談拿到我裏面的東西，對不對？

如今咱們把個人http通道，變成了https，同時關閉80端口，所以用用戶要訪問必須通過443端口。好了，咱們再來用:

telnet localhost 443

你連telnet都進不進去，所以，你就沒法再獲取http通道內傳輸的東西了。所以黑客要進入你的網站先要突破這個https，而https使用的是 RSA非對稱128位加密，若是是安全交易類甚至會使用RSA 1024位加密算法，除非是世界上最高明的黑客才能突破咱們的防線。

2.2 HTTPS的構成

要構成HTTPS，咱們須要有一張「根證書」，一張「服務器認證」才能作到通常的https，HTTPS還分紅「雙向認證」，在雙向認證的結構中咱們須要3 張證書即「根證書」，「服務器認證」，「客戶端認證」。爲何須要這麼多證書？嘿嘿，下面咱們來看HTTPS是怎麼構成這個「信任關係鏈」的。

ü 證書咱們稱爲CA；

ü 根證書叫Root CA；

上述這個圖什麼意思？

首先，RootCA是全球的根，這個「樹」的根是全球任何IE、FireFox、Safari裏的證書庫裏都有這個RootCA的，由於它們是權威，因此全球的電子證書拿它們作「根」，這些證書比較具備表明性的是：

ü Verisign

ü RSA

這兩家公司是世界上全部加密算法的「鼻祖」，所以被拜爲全球所信任，咱們能夠在咱們的IE中看到這些「根」。

其此，全球的計算器客戶默認在裝完系統後，都會帶有這些ROOT CA，所以「由ROOT CA簽出來的服務器證書將自動被客戶端所信任」。

因此，這個信任關係，就此創建。

在HTTPS是SSL的一種，它們間是如何進行加密傳輸的呢，就是這個「信任關係」，先創建起信任關係，而後再開始數據傳輸，在加密的世界中「創建信任」就須要用到至少2張證書，即ROOT CA， SERVER CA，咱們把這個信任創建的過程稱爲「Hands Shake」，握手協議。

前面說到了，這個握手分單向和雙向，包括上述這個圖就是一個單向握手，什麼叫單向，什麼叫雙向呢？咱們下面來說解：

ü 單向握手信任

咱們又稱它爲「包二奶協議」，你們想一下，貪官包二奶和二奶說「你跟着我，我每個月給你1萬塊」，他說的這個話，能不能寫下來？能嗎？固然不能，寫下來還得了，未來二奶一不爽把這份白紙黑字的東西交到中紀委還不把這爛貨給雙規了哈？

因此，二奶單向裏信任貪官，這就是二奶協議，即客戶端認爲我訪問的這臺服務器「是安全的」，所以客戶端能夠向服務器發送和提交任何東西。

ü 雙向握手信任

咱們又稱它爲「君子協定」，呵呵，從這個詞表面上來看就知道這個協議有多牢靠了，首先，它是寫在字面上的，其次，雙方都簽署協議這個信任關係怎麼樣啊？很是牢靠！

即客戶端信任服務器，所以客戶端能夠向服務器發送和提交任何東西。同時，服務器也信任客戶端，容許該客戶端向我發送和提交東西。

客戶端單向信任服務器很簡單，只要這個服務器是我客戶端信任的頂級根簽發出來的證書就行，而服務器如何信任客戶端呢？記住下面三句話：

首先，你這個客戶端到我這邊來登記一下；

其次，我給你籤一張證書，你帶回家裝在你的IE裏；

最後，每次訪問時由於你的IE裏裝着我服務器簽出的證書，因此你是個人會員，因此我信任你；

2.3 證書與如何生成證書的基本概念

經過上面的概念，咱們知道了，若是創建起這個HTTPS的環境咱們須要至少一張服務器證書，對不對？並且這張服務器證書是須要由客戶端信任的「ROOT」級機構所簽發出來的。

因此通常生成證書由如下幾個步驟構成：

1. 生成一對不對稱密鑰，即公鑰public key和私鑰 private key

2. 用密鑰產生請求，同時把個人請求交給ROOT機構

3. ROOT機構對我提交的請求進行「簽名」Sign

這個被簽完名後的「請求」就稱爲證書。

上面多出來了密鑰，公鑰，私鑰三個名詞，下面來作解釋。

先來看一個真理：

1）密鑰，密鑰爲一對，即一把公鑰，一把私鑰

2）一把私鑰能夠對應多把公鑰，而這些公鑰只可能來源於一把私鑰

3）公鑰加密，私鑰解密

你們想一下，公鑰加密，這是「公」就是人人有這把KEY，均可以用來加密，可是能打開我這扇門的因該只有一我的是吧？這就是爲何說「私鑰」解密。

倒過來

私鑰「加密」（被稱爲簽名），公鑰「解密」（被稱爲認證）

把上面這個「真理」倒過來，呵呵，好玩了，由於public key只能用來加密而解密必須是private key，所以公鑰是不能加密的，公鑰也不能用來解密，那麼它們該怎麼作？

HP公司是賣打印機的，它有100個代理，都爲它銷售打印機。

客戶來到了某個代理公司，問：你憑什麼說你是HP的代理

代理公司說：請看，這是HP公司給我證書

客戶問：你的證書不能僞造嗎？

代理公司答：請看，下面有一個防僞條形碼

因而，客戶把這個防僞條形碼用手機拍下來，來到HP公司說：這是否是大家的代理？

HP公司說：你等一下！ 隨後HP公司拿出之前給這家代理公司的公鑰，對這個簽名作一個「解密」（被稱爲雜湊算法），也算出來一個防僞條形碼，而後拿這個防僞條形碼和客戶帶來的防僞條形碼一比較，徹底一致，因此HP和客戶說：您能夠徹底相信這家公司，這家公司是我代理的。

這邊這個防僞條形碼就是代理公司用HP在頒發證書時給它時用HP的私鑰的「簽名」；

HP公司用爲當初給代理商發放證書時同時生成的密鑰對裏的公鑰對這個籤個名作一個雜湊算法，而後拿算出來的防僞條形碼再和客戶帶來的這個防僞條形碼比對的這個過程被稱爲「認證」；

一塊兒來看看證書裏的防僞條形碼吧

咱們把它稱爲電子「指紋」，通常用的是SHA或者是MD5算法，由於MD5和SHA是不可逆惟一性算法，因此把它比喻成「指紋」再恰當不過了。

2.4 實際開發實驗中如何產生證書

實際產生證書時，咱們須要生成請求，但不是說咱們把請求交給Verisign或者一些信息機構，它們就幫咱們籤的，這是要收費的，通常籤個名：50-500美金不等，有時還分爲每一年必須去籤一次，要否則就會失效。

因此咱們在實際開發環境中，爲了作實驗或者是搭建模擬環境，不可能會去花錢買個證書的，有時咱們環境要搭建幾套，怎麼辦？這錢花的沒有明堂的。

因此，在實際開發環境中，咱們本身來模擬這個ROOTCA，而後用本身模擬出來的ROOTCA去籤咱們服務器的證書，這個過程就被稱爲「自籤」。

2.5 使用OpenSSL來簽證書

OpenSSL 就是這麼一個自籤，加密的命令行工具，它是從UNIX下分離出來的一個項目，但也有FOR WINDOWS平臺的，好比說我給大家用的這個OPENSSL，就是For WIN的，可是因爲它是從UNIX/LINUX下產生的，所以它內部的配置仍是用的是LINUX/UNIX的盤符與路徑，須要手動去校訂，固然我已經作好了校訂，所以直接打了個壓縮包放在了FTP上，你們拿下來後解壓後就能夠直接用了。

若是大家是本身從網上官方網站下載的OPENSSL須要手動去改它的盤符和路徑，要否則是用不起來的。

ü 設置環境變量

把c:\openssl\bin\openssl.cnf設成OPENSSL_CONF這樣的一個變量，同時把c:\openssl\bin目錄加到你的path裏去（根據大家本身的解壓後的openssl的實際路徑）。

ü 生成根證書所用的密鑰

提示輸入密碼咱們使用：aaaaaa

再次輸入確認密碼

（密鑰，由其是private key是由口令保護的）

去除CA密鑰的口令

爲何咱們要把好好的口令保護給去除呢？這邊不是去除而是表明這個證書在被應用程序啓動時不須要顯示的提示用戶輸入口令，要否則咱們會出現下面這種狀況：

在啓動HTTPS協議的服務器時，通常咱們點一下service->apache2.x啓動，就啓動了，但若是這個https所帶的證書是沒有通過上述這道手續後處理的話，這個服務在啓動時會失敗，而須要切換成手動命令行啓動，就是黑屏！在黑屏狀態下，apache2.x服務器啓動時會提示你要求：輸入口令，這個太麻煩了，通常啓動服務器服務的必定是超級管理員，所以通常狀況下不必在啓動相關服務時再輸入一遍口令了。

ü 生成CA即ROOT CA證書並自籤

網上有不少說法，說是先產生CA的Request請求，再用ca.key去自籤，我給你們介紹一條一步到位的產生ca ROOT證書的命令，爲了安全，咱們在最後加上「-configC:\openssl\bin\openssl.cnf」，以使openssl工具能夠找到相應的config文件（有些系統在指定了OPENSSL_CONF環境變量後通常就不須要在命令行裏去手工指定這個-config變量了）。

因爲咱們產生的證書爲:X509格式，所以須要按照X509格式填入相關的值。

² AU-國家家的縮寫，如：CHINA=CN，美國=USA，英國=UK，日本=JP

² State or Province Name-省/洲的縮寫或者是全稱，如：上海=SH

² Locality Name-城市的全稱或者是縮寫，如：上海=SH

² Organization Name-公司名，如：Cognizant

² Common Name-要安裝這臺證書的主機名，證書是和主機名綁定的，若是證書裏的主機名和你實際的主機名不符，這張證書就是非法的證書。

咱們不可以填IP，必定必定要填主機名即域名www.xxx.com這樣的東西，好比說我填的是shnlap93，但個人主機怎麼知道shnlap93是指:10.225.106.35或者說是指localhost這臺機器呢？

打開C:\Windows\System32\drivers\etc\hosts這個文件，以下：

localhost shnlap93

10.225.106.35 shnlap93

看到了吧？因此當咱們使用pint shnlap93時，它是否是就能夠知道shnlap93=10.225.106.35啦？

EmailAddress-郵件地址，愛填不填，能夠跳過，反正咱們是「自籤」。

Look，咱們的CA證書生成了，能夠雙擊這張證書，查看信息後關閉它。

目前這張ROOT 證書，只是個自籤的產品，由於是自籤，通常其它客戶端的IE裏所以是不會帶有這張根證書的。

要其實客戶端也能信任這張根證書，咱們必須怎麼辦？

將它安裝到咱們的IE的信任域裏。

ü 將ROOT CA導入客戶端的根級信任域，有多少臺客戶端，每一個客戶端都要導一邊這個證書！

因此說若是咱們擁有世界級的根證書該多好啊，電腦上默認就帶有咱們的證書，所以知道這幫世界級的根證書機構爲何能掙錢了吧？50-500美金籤張證書，幾秒鐘的事，CALL！！！

點[導入]按鈕

下一步，下一步，此時會有一個彈出框，選「yes（是）」完成導入。

再來打開咱們的ca.crt文件

發現了沒有，這張證書是有效的證書了，因此在「證書信息」前原有的一個紅叉叉，消失了。

ü 生成Web服務器端證書密鑰

咱們的root證書有了，如今能夠生成Web服務器端的證書了，而且用root ca去簽名

先生成密鑰，密碼6個a

去除密碼（提示：enter pass phrase for server.key時輸入剛纔生成密鑰時的密碼即6個a。

ü 生成Web服務器端證書的簽名請求

生成服務器端證書請求時須要輸入server端key的口令，咱們爲了方便，也用6個a。

ü 用Root CA去對Web服務器的證書請求即csr(certificate request)進行簽名認證

輸入y並回車

此時它會提示：

1 out of 1certificate requests certified, commit? [y/n]，再輸入y並回車

Web服務器的server.crt證書生成完畢。

注：

若是在操做時有任何錯，必須連同生成的.key,.csr, .crt文件所有刪除重頭來一遍

咱們來看看，這個server.crt文件，雙擊它。

首先，咱們看到該證書的「證書信息」前沒有紅色的大叉，而後是證書信息正是咱們剛纔輸入的內容，爲何沒有大叉？

由於咱們的RootCA根證書裝在咱們IE的根級信任域裏，又由於咱們的客戶端信任咱們的RootCA，所以當咱們的客戶端打開由RootCA簽出來的server.crt時，這根「信任鏈」被創建了起來，因此客戶端自動單向信任咱們的server.crt，對不對？

下面咱們來作一個實驗，把咱們的Root CA從咱們的根級信任域中刪除。

選中這個shnlap93的根級證書，點[刪除]，會彈出兩次確認框，選「yes」確認刪除掉它。

關閉IE，而後咱們再次雙擊咱們的server.crt文件，來查看證書內容。

咱們看到了什麼？「不能驗證該證書。

從新導入咱們的Root CA至IE的根級信任域（見將ROOT CA導入客戶端的根級信任域）。

再次打開server.crt查看證書內容。

一切回覆正常了。

2.6 爲Apache HttpServer佈署https協議

ü 用文本編輯器打開httpd.conf文件，找到以下這一行

#Include conf/extra/httpd-ssl.conf

這行默認是被註釋掉的，所以請把它放開，修改爲以下

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目錄內。

在httpd.conf文件中搜索「ServerName」

搜到下面這樣的一句

ServerName 10.225.101.35:80

把它改爲你的主機名

ServerName shnlap93:80

此處的shnlap93是你的主機名

再繼續在httpd.conf文件中搜索「VirtualHost *」

搜到下面這一句

把它改爲

在D:\tools\httpd\conf\extra\httpd-ssl.conf文件中查找

搜「VirtualHost _default_:443」

而後把位於< VirtualHost _default_:443>段內的頭三行改爲以下格式

² 確保你的http的發佈目錄在d:/www

² 確保你的HTTPS的主機名爲shnlap93:443(這邊的名字和生成證書裏的common name必須徹底如出一轍連大小寫都必須同樣)

DocumentRoot "D:/www"

ServerName shnlap93:443

ServerAdmin admin@localhost

而後在下一個「</VirtualHost> 」結束前，填入下面這幾行語句

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服務前先Test Configuration一下，若是一切無誤，能夠重啓了。

而後咱們來實驗一下咱們的Web Server的https的效果

看到沒有，這個紅圈圈起來的地方，目前是正常的，顯示金黃色的一把鑰匙。

若是你的Root CA沒有裝入IE的根級信任域，此時你敲入https://shnlap93/cbbs時，你會被提示說「該證書不被任何」，而後讓你點一下「確認」按鈕，點完信任後能進入咱們的Web應用，可是，原先應該顯示「金黃色鑰匙」的地方會顯示一個紅色的圈圈，而且當你查看證書信息時，這個地方也會顯示「證書不受信任」，而且顯示一個紅色的大叉。

2.7 爲Tomcat也佈署https協議

咱們的Apache HttpServer已經走https協議了，不是已經enough了嗎？NO，遠遠不夠，若是你沒有用到任何App Server即tomcat/weblogic/was那麼咱們說咱們的應用已經走https協議了，可是由於咱們的架構是Web Server + App Server，所以，咱們的App Server也必須走https協議。

若是隻是Web Server走https協議，而App Server沒有走https協議，這就叫「假https架構」，是一種極其偷賴和不負責任的作法。

概念同產生Apache的HttpServer的證書同樣，只是這邊的信任域有點不同。

Web的信任域就是你的IE裏的內容裏的證書裏的「根級信任域」，App Server的信任域是打不開也不能訪問這塊地方的，並且App Server的信任域格式也不是crt文件，而是.jks(javakey store的簡稱)。

下面來作一個tomcat的https佈署。

原有ca.crt和ca.key繼續有用，由於ROOT CA都是一個，並且必須必定始終是惟一的一個，對吧？

咱們直接從server.jks來作起。

說JKS，這東西好玩的很，jks文件其實就是把key文件與crt文件合在一塊兒，以java key store的格式來存儲而己。

2.8 生成Tomcat的SSL證書

爲Tomcat的server所在的服務器生成一個server.jks文件

不少網上的資料是拿原先的server.crt文件轉成keystore文件，實際上是不對的，須要單獨生成一張server.jks文件。

怎麼生成證書？回顧一下上文：

1）生成KEY

2）生成證書請求

3）用CA簽名

下面開始使用%JAVA_HOME%\bin目錄下的keytool工具來產生證書

ü 生成JKS密鑰對，密碼使用6個a，alias表明「別名」，CN表明Common Name，必須與主機名徹底一致，錯了不要怪我本身負責。

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結合ca.crt與ca.key爲jsk的csr來簽名認證併產生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時選yes

因而，咱們有了一張符合jks格式的crt證書叫shnlap93.crt文件，來查看它。

證書上沒有紅色的大叉，由於咱們的Root CA裝在咱們的IE的根級信任域中，OK，下面來了，生成這個JKS，就是把crt和key合在一塊兒，來了！

ü 生成符合x509格式的jks文件

1) 將Root CA導入jks信任域

keytool -import -alias rootca -trustcacerts -file ca.crt -keystore shnlap93.jks -storepass aaaaaa

前面我說了，jks信任域是讀不到IE的根級信任域的，所以要手動把ca.crt文件導入jks的信任域

1) 如今咱們的shnlap93.jks文件中有兩個realm(域)，一個是：

² 自己的csr(產生的籤書請求認證的域，還沒被認證，由於認證的內容變成了shnlap93.crt文件了是否是？)

² 剛纔步驟中導入的Root CA認證域

那麼客戶端信任Root CA沒有問題，但因爲server端自己的信任域還只是處於「請求被簽名」的狀態，那麼客戶端如何去信任這個jks文件呢？

答案就是：補鏈，補這根信任鏈！

keytool -import -alias shnlap93X509 -file shnlap93.crt -keystore shnlap93.jks -storepass aaaaaa

咱們不是生成過shnlap93.crt嗎？把它導入jks不就是可以把原有的「正在處於請求被簽名認證」這個狀態改爲「已經被Root CA簽名認證」了嗎？對吧？

因此，咱們用於佈署tomcat的ssl證書的jks格式的文件shnlap93.jks已經完整了。

2.9 佈署Tomcat上的Https協議

Apache HttpServer走的是443端口，Tomcat走的就是8443端口。

打開tomcat的conf目錄下的server.xml，咱們來找下面這一段：

<!--

<Connector executor="tomcatThreadPool"

port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443"

-->

默認狀況下，它是被由「」這樣的標籤給註釋起來的，咱們把它放開

² clientAuth=」false」

若是該值爲」true」就表明要啓用雙向認證

² keystoreFile就是咱們生成的keystore文件所在的徹底路徑

² keystorePass就是咱們生成keystore時的password

重啓tomcat,輸入https://shnlap93:8080/cbbs, 能夠看到登陸網頁,且右上方的SSL鏈接信息爲「金黃色的鑰匙」而不是紅色大叉，那麼一切就成功了。

重啓Apache，而後在ie地址欄輸入: https://shnlap93/cbbs，用sally/abcdefg，一切成功。

注意：

當啓用了https協議後，你在ie地址欄就不能再用localhost了，爲何？由於咱們的證書中的CN(Common Name)填入的是主機名，若是你還用:https://localhost，那麼你也能正常進入網址，只是多了幾步https不被信任的警告框，而且你右上角的ssl鏈接信息爲紅色的大叉，對於這樣的https鏈接，若是換成是購物網站，你敢信任嗎？