Configuring SSL in Wildfly 8

Configuring SSL in Wildfly 8

一:什麼是SSL

　　SSL（Security Socket Layer）全稱是加密套接字協議層，它位於HTTP協議層和TCP協議層之間，用於創建用戶與服務器之間的加密通訊，確保所傳遞信息的安全性，同時SSL安全機制是依靠數字證書來實現的。

　　SSL基於公用密鑰和私人密鑰，用戶使用公用密鑰來加密數據，但解密數據必須使用相應的私人密鑰。使用SSL安全機制的通訊過程以下：用戶與服務器創建鏈接後，服務器會把數字證書與公用密鑰發送給用戶，用戶端生成會話密鑰，並用公共密鑰對會話密鑰進行加密，而後傳遞給服務器，服務器端用私人密鑰進行解密，這樣，用戶端和服務器端就創建了一條安全通道，只有SSL容許的用戶才能與IIS服務器進行通訊。

　　提示：SSL網站不一樣於通常的Web站點，它使用的是「HTTPS」協議，而不是普通的「HTTP」協議。所以它的URL（統一資源定位器）格式爲「https://網站域名」。

二:密碼學的相關概念

密碼學(cryptography)：目的是經過將信息編碼使其不可讀，從而達到安全性。

明文(plain text)：發送人、接受人和任何訪問消息的人都能理解的消息。

密文(cipher text)：明文消息通過某種編碼後，獲得密文消息。

加密(encryption)：將明文消息變成密文消息。

解密(decryption)：將密文消息變成明文消息。

算法：取一個輸入文本，產生一個輸出文本。

加密算法：發送方進行加密的算法。

解密算法：接收方進行解密的算法。

密鑰(key)：只有發送方和接收方理解的消息

對稱密鑰加密(Symmetric Key Cryptography)：加密與解密使用相同密鑰。

非對稱密鑰加密(Asymmetric Key Cryptography)：加密與解密使用不一樣密鑰。

三:SSL的單向認證和雙向認證

單向認證

基於ssl，通常的應用都是單向認證，若是應用場景要求對客戶來源作驗證也能夠實現成雙向認證。

爲了便於更好的認識和理解 SSL 協議，這裏着重介紹 SSL 協議的握手協議。SSL 協議既用到了公鑰加密技術又用到了對稱加密技術，對稱加密技術雖然比公鑰加密技術的速度快，但是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議很是有效的讓客戶和服務器之間完成相互之間的身份認證，其主要過程以下：

       ① 客戶端的瀏覽器向服務器傳送客戶端 SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其餘服務器和客戶端之間通信所須要的各類信息。

　　② 服務器向客戶端傳送 SSL 協議的版本號，加密算法的種類，隨機數以及其餘相關信息，同時服務器還將向客戶端傳送本身的證書。

　　③ 客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過時，發行服務器證書的 CA 是否可靠，發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過， 通信將斷開；若是合法性驗證經過，將繼續進行第四步。

　　④ 用戶端隨機產生一個用於後面通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。

　　⑤ 若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶能夠創建一個隨機數而後對其進行數據簽名，將這個含有簽名的隨機數和客戶本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。

　　⑥ 若是服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的 CA 是否可靠，發行 CA 的公鑰可否正確解開客戶證書的發行 CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗若是沒有經過，通信馬上中斷；若是驗證經過，服務器將用本身的私鑰解開加密的「預主密 碼」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。

　　⑦ 服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於 SSL 協議的安全數據通信的加解密通信。同時在 SSL 通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。

　　⑧ 客戶端向服務器端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。

　　⑨ 服務器向客戶端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。

　　⑩ SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。

雙向認證 SSL 協議的具體過程

       ① 瀏覽器發送一個鏈接請求給安全服務器。

　　② 服務器將本身的證書，以及同證書相關的信息發送給客戶瀏覽器。

　　③ 客戶瀏覽器檢查服務器送過來的證書是不是由本身信賴的 CA 中心所簽發的。若是是，就繼續執行協議；若是不是，客戶瀏覽器就給客戶一個警告消息：警告客戶這個證書不是能夠信賴的，詢問客戶是否須要繼續。

　　④ 接着客戶瀏覽器比較證書裏的消息，例如域名和公鑰，與服務器剛剛發送的相關消息是否一致，若是是一致的，客戶瀏覽器承認這個服務器的合法身份。

　　⑤ 服務器要求客戶發送客戶本身的證書。收到後，服務器驗證客戶的證書，若是沒有經過驗證，拒絕鏈接；若是經過驗證，服務器得到用戶的公鑰。

　　⑥ 客戶瀏覽器告訴服務器本身所可以支持的通信對稱密碼方案。

　　⑦ 服務器從客戶發送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密後通知瀏覽器。

　　⑧ 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接着用服務器的公鑰加過密後發送給服務器。

　　⑨ 服務器接收到瀏覽器送過來的消息，用本身的私鑰解密，得到通話密鑰。

　　⑩ 服務器、瀏覽器接下來的通信都是用對稱密碼方案，對稱密鑰是加過密的。 

上面所述的是雙向認證 SSL 協議的具體通信過程，這種狀況要求服務器和用戶雙方都有證書。單向認證 SSL 協議不須要客戶擁有 CA 證書，具體的過程相對於上面的步驟，只需將服務器端驗證客戶證書的過程去掉，以及在協商對稱密碼方案，對稱通話密鑰時，服務器發送給客戶的是沒有加過密的 （這並不影響 SSL 過程的安全性）密碼方案。 這樣，雙方具體的通信內容，就是加過密的數據，若是有第三方攻擊，得到的只是加密的數據，第三方要得到有用的信息，就須要對加密的數據進行解密，這時候的 安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通信密鑰長度足夠的長，就足夠的安全。這也是咱們強調要求使用 128 位加密通信的緣由。

四: 生成私鑰和公鑰

JDK有keytool來提供生成密鑰庫.

1. alias：證書名稱

2. keyalg:生成證書採用的算法，如RSA

3. sigalg：簽名算法,這一算法必須與 keyalg 兼容

4. keysize:證書密鑰長度 如1024

5. validity：證書有效時間，以日爲單位

6. keystore：用於指定保存密鑰庫的文件名

7. storepass：訪問證書庫的密碼

8. storetype:證書庫類型 如pfx，jks，pkcs12等

9. provider：證書提供者，默認不寫爲SUN

1.「名字與姓氏」應該是域名，若輸成了姓名，和真正運行的時候域名不符，會出問題;

2.  再次輸入密碼，第一次輸入的是密鑰庫(keystore)的密碼，第二次輸入的是證書條目的密碼

具體記錄以下：

======================命令==========================================

D:\>keytool -genkey -keystore cdi-init.keystore -alias cdi-init -keyalg RSA -keysize 2048 -validity 3650

輸入密鑰庫口令:[zhaoqian]

再次輸入新口令:

您的名字與姓氏是什麼?

[Unknown]: localhost

您的組織單位名稱是什麼?

[Unknown]: cdi-init

您的組織名稱是什麼?

[Unknown]: cdi-init.org

您所在的城市或區域名稱是什麼?

[Unknown]: beijing

您所在的省/市/自治區名稱是什麼?

[Unknown]: beijing

該單位的雙字母國家/地區代碼是什麼?

[Unknown]: cn

CN=loaclhost, OU=cdi-init, O=cdi-init.org, L=beijing, ST=beijing, C=cn是否正確?

[否]: y

輸入 <tomcat> 的密鑰口令

(若是和密鑰庫口令相同, 按回車):

================================================================

D盤下生成 cdi-init.keystore .將此文件放到JBOSS/Wildfly下的..\standalone\configuration文件夾下.

======================命令========================================

keytool -export -alias cdi-init -keystore cdi-init.keystore -storepass zhaoqian -rfc -file cdi-init.cer

將生成一個cdi-init.cer 文件.

=================================================================

五:配置JBOSS7,EAP6的單向認證

standalone.xml下加入

<extension module="org.jboss.as.web"/>

再配置

<subsystem xmlns="urn:jboss:domain:web:1.5" default-virtual-server="default-host" native="false">

            <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>

            <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">

                <ssl name="ssl" key-alias="cdi-init" password="zhaoqian" certificate-key-file="${jboss.server.config.dir}/cdi-init.keystore" protocol="SSLv2+SSLv3"/>

            </connector>

            <virtual-server name="default-host" enable-welcome-root="false">

                <alias name="localhost"/>

                <alias name="example.com"/>

                <access-log/>

            </virtual-server>

        </subsystem>

更詳細說明: http://docs.jboss.org/jbossweb/7.0.x/ssl-howto.html 

六:配置wildfly https 單向認證

wildfly配置SSL已和jboss7[EAP6]不同,發生了變化.內置的servlet容器由tomcat變爲了undertow,所以SSL的配置也發生了變化.

xml namespace  已經由 urn:jboss:domain:web:1.X 變爲了 urn:jboss:domain:undertow:1.x

步驟一,security-realms下添加節點數據:

<security-realms>

    ...

    <security-realm name="SslRealm">

        <server-identities>

            <ssl>

                <keystore path="cdi-init.keystore" relative-to="jboss.server.config.dir" keystore-password="zhaoqian"/>

            </ssl>

        </server-identities>

    </security-realm>

</security-realms>

步驟二,配置節點下的數據,添加一個新的https-listener 

<subsystem xmlns="urn:jboss:domain:undertow:1.0">

    ...

    <server name="default-server">

        <http-listener name="default" socket-binding="http"/>

        <https-listener name="https" socket-binding="https" security-realm="SslRealm"/>

        <host name="default-host" alias="localhost">

            <location name="/" handler="welcome-content"/>

            <filter-ref name="server-header"/>

            <filter-ref name="x-powered-by-header"/>

        </host>

    </server>

    ...

</subsystem>

參考: http://reallifejava.com/configuring-ssl-in-wildfly-8/ 

http://docs.jboss.org/keycloak/docs/1.0-alpha-1/userguide/html/server-installation.html

七:配置wildfly的雙向認證

步驟同五.兩處要進行修改

<security-realm name="SslRealm">

<server-identities>

<ssl>

<keystore path="cdi-init.keystore" relative-to="jboss.server.config.dir" keystore-password="zhaoqian"/>

</ssl>

</server-identities>

<authentication>

<truststore path="cdi-init.truststore" relative-to="jboss.server.config.dir" keystore-password="zhaoqian" />

<local default-user="$local"/>

<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>

</authentication>

</security-realm>

2.

<https-listener name="default-ssl" socket-binding="https" security-realm="SslRealm" verify-client="REQUIRED" />

發現一個異常,是

WARN  [org.atmosphere.cpr.AtmosphereFramework] (MSC service thread 1-8) No BroadcasterCache configured. Broadcasted message between client reconnection will be LOST. It is recommended to configure the org.atmosphere.cache.UUIDBroadcasterCache

和websocket有關,暫時我不使用websocket,因此只是粗略看了看.

http://stackoverflow.com/questions/24514169/primefaces-push-and-wildfly 

我也只是使用也是使用單向的https.沒使用過雙向https.

JBOSS官網資料:

https://docs.jboss.org/author/display/WFLY8/Undertow+subsystem+configuration

https://docs.jboss.org/author/display/WFLY8/Examples