安全管理，以及證書申請

1.1 網絡安全知識

1.1.1 網結安全出現背景

網絡就是實現不一樣主機之間的通信，網絡出現之初利用TCP/IP協議簇的相關協議概念，已經知足了互連兩臺主機之間能夠進行通汛的目的，雖然看似簡簡單單幾句話，就描述了網絡概念與網絡出現的目的，可是爲了真正實現兩臺主機之間的穩定可靠通信，實際上是一件很是困難的事情了，若是還要再通信的基礎上保證數據傳輸的安全性，可想而知，絕對是難上加難，所以，網絡發明之初，並無太關注TCP/IP互聯協議中的安全問題。php

對於默認的兩臺主機而言，早期傳輸數據信息並無經過加密方式傳輸數據，設備兩端傳輸的數據自己實際是明文的，只要能截取到傳輸的數據包，就能夠直接看到傳輸的數據信息，因此根本沒有安全性可言。html

1.1.2 網絡安全涉及問題

早期網絡設備間進行通信時，是採用明文逬行數據傳輸的，並無網絡安全技術可言。咱們能夠提出一種假設，若是在網絡上的兩臺主機之間傳輸數據，就是採用明文的方式；而且對於網絡傳輸而言，並無相關的網絡安全技術保駕護航，這樣在互聯網上進行數據傳輸，都有哪些網絡風險須要進行面對。nginx

Ø 網絡安全問題--數據機密性web

在網絡傳輸數據信息時，對數據的加密是相當重要的，不然全部傳輸的數據都是能夠隨時被第三方看到，徹底沒有機密性可言。算法

Ø 網絡安全問題--數據完整性shell

網絡傳輸數據的完整性，也是安全領域中齋要考慮的裏要環節，若是不能保證傳輸數據的完整性，那傳輸過程當中的數據就有可能被任何人所篡改，而傳輸數琚雙方又不能及早的進行發現，將會形成互連通汛雙方所表達信息的意義徹底不一致。所以，對於不芫整的數據信息，接收方應該進行相應判斷，若是完整性驗證錯誤，就拒絕接收相應的數據。瀏覽器

Ø 網絡安全問題--身份驗證問題緩存

網絡中傳輸數據時，頗有可能傳輸的雙方是第一次創建鏈接，進行相互通信，既然是第一次見面溝通，如何確認對方的身份信悤，的確是我要進行通信的對象呢？若是不是正確的通信對象，在通過通信後，豈不是將全部數據信息發送給了一個陌生人。安全

1.2 網絡安全問題的解決

1.2.1 網絡安全解決問題--如何保證數據的機密性

Ø 數據機密性解決思路--利用普通算法解決機密性服務器

爲了保證數據的機密性，首先能夠採用的方法就是將數據經過相應算法，轉換爲其它的數據信息，而後再經過相應算法反推出真正的數據是什麼，這樣一來就保證了數據在網絡傳輸過程當中安全性，不會被其它人輕易的看到傳輸過程當中的數據信息.數據加密前的信息稱爲明文數據（plaintext）,通過加密算法轉換後進行傳輸的信息稱爲密文數據（ciphertext）;反之通過解密算法轉換後，會將密文數據恢復爲明文數據進行顯示接收。

圖 - 數據機密性處理示意圖

l 優勢：

實現了數據機密傳輸，避免了明文傳輸數據的危險性。

l 缺點：

利用加密算法，將明文改密文，若是第三方得到加密算法，便可將傳輸密文再次變爲明文

Ø 數據機密性解決思路--利用對稱加密算法解決機密性

普通算法雖然已經解決了明文數據的機密性，能夠在網絡傳輸過程當中不被直接看到明文數據。可是新的問題又產生了，既然明文數據是經過算法改變成了新的數據信息，若是第三方得到了算法，利用算法也是能夠將密文數據信息，再次轉換爲明文數據信息，所以出現了對稱加密算法，形象比喻來講：數據加密算法就比如是一本密碼規則手冊，而對稱加密算法就是將手冊放在了一個保險櫃中進行了上鎖傳輸，只有傳遞數據信息的雙方知道打開保險櫃的密碼。

圖 - 數據機密性處理示意圖

1.2.2 網絡安全解決問題-如何保證數據的完整

Ø 數據完整性解決思路--利用單項加密算法

利用數據的單項加密算法（提取數據指紋），進行提取數據特徵碼的方式，從而完成數據傳輸的完整性驗證.實際的算法實現過程爲：在一段明文數據信息後加上數據信息的特徵碼，這個特徵碼是經過結合數據信息進行相應算法得到的數據特徵碼，接收方當收到數據信息後，會利用相同的加密算法對獲取的數據進行加密，確認加密後獲得的特徵碼是否與傳送過來數據後面描述的特徵碼一致；若是一致，能夠表示數據沒有被篡改過，若是不一致表示數據完整性遭到了破壞，數據一律不予以接收處理。

Ø 數據完整性解決思路--利用單項加密算法（加密特徵碼）

因爲可能存在中間人攻擊的可能性，所以能夠對傳輸過程當中數據特徵碼進行加密，發送方利用對稱密鑰方式對手中的特徵碼進行加密，接收方會利用相同的密鑰對手中的特徵碼進行解密，從而確認特徵碼是否一致.若是中間人將新的特徵碼也進行了加密，發送給接收方，但接收方沒法利用和發送方協商好的解密密鑰對特徵碼進行解密，最終沒法識別中間人發送過來的數據特徵碼信息。

在此須要瞭解一下加密算法的原理 ↓

通信雙方須要進行數據密鑰信息約定（密鑰協商過程），在密鑰相互能夠獲悉的過程當中，須要藉助密鑰交換機制（Internet key exchange IKE）,進而實現密鑰的交互。爲了知足網絡中，兩臺主機間密鑰交換統一的過程，須要引入一種新的協議diffie-hellman協議。

diffie-hellman協議算法實現的過程：

1) 首先發送方選取一個大素數P(只能被1和本身整除的數)，再選取一個生產數g ,而且發送方將P與g通過互聯網傳輸到接收方。

2) 數據傳輸的兩端，發送方選取一個隨機數x,接收方選取一個隨機數y;發送方只知道隨機數x ,接收方只知道隨機數y , x和y不在互聯網上進行傳輸。

3) 接收數據雙方開始進行計算，對於發送方進行計算g的x次方對P取模的結果，傳輸給接收者；而接收方進行計算g的y次方對P取模的結果，傳輸給發送者。

4) 此時對於接收方獲取到了發送方的g的x次方對P取模的結果，在取模結果的基礎上進行y次方的運算，y就是接收方自身產生的隨機數y;而對於發送方獲取到了接收方的g的y次方對P取模的結果，在取模結果的基礎上進行x次方的運算。x就是發送方自身產生的隨機數x#這次，雙方的加密運算密鑰就實現了交換，而且是統一一致的，最終的密鑰爲g的xy次方對P取模的結果。

圖 - diffie-hellman協議算法示意圖

經過diffie-hellman協議算法最終能夠實現了網絡傳輸雙方的密鑰交換，而且通信的雙方也今後不用再對密鑰進行管理記憶，只須要在進行傳輸數據前，逬行一次密鑰的交換過程；即完成了對稱密鑰的生成過程。

而且若是網絡中有攻擊者在嘗試破解出交換密鑰時，就算經過比較複雜的數學運算，獲悉了密鑰，但也只是瞭解了上一次的數據交換密鑰信息；下一次數據傳輸雙方通信時，還會交換新的密鑰用於新的數據傳輸。

1.2.3 網絡安全解決問題-如何進行傳輸雙方身份驗證

Ø 網絡安全身份驗證解決方案

以上信息只是解決密鑰的交換獲取問題，可是網絡的身份驗證問題依舊沒有逬行解決，換句話說，通信雙方的確能夠獲取統一的密鑰信息了，而且是經過相對安全的方式獲取得知的，可是通信雙方在交換獲取密鑰前，又怎麼確認得知，交換密鑰的對方的確是要逬行通信的發送方或接收方呢？

Ø 安全身份驗證解決思路-利用非對稱密鑰加密箅法（公鑰加密算法）

利用非對稱加密算法（公鑰加密算法），能夠從根本上有效解決網絡中，數據傳輸雙方的安全身份驗證問題。非對稱加密算法中，存在密鑰對的概念，即擁有公鑰（public key）與私鑰（pnvate key）,其中公鑰不是自行建立出來的而是從私鑰中提取出來一部分做爲公鑰，所以能夠說公鑰是來自於私鑰的，而私鑰才決定了密鑰加密的安全性，因而私鑰的長度可能會很是長，從最初的1024,2048,到4096一直到更多的位數，將私鑰密鑰位增長的很長，從而提高了密鑰安全性。

利用非對稱加密算法，須要遵循一個基本原則：公鑰加密的只能利用與之配對的私鑰進行解密，反之也是一祥的.可是非對稱加密算法並不能用於對數據完整性進行驗證，由於私鑰只有一份，但公鑰能夠有不少份。儘管非對稱加密算法不能知足數據完整性驗證，但徹底能夠知足對傳輸者身份驗證的需求，由於接收者能夠擁有相應的公鑰，只有與之對應的發送者用相應的私鑰進行加密信息，用對應的公鑰天然便可解密，不然能夠確認發送者身份已經發生了變化。

1.3 證書的由來

1.3.1 如何獲取公鑰信息

默認公鑰在網絡中進行傳遞時，默認狀況下也是會出現問題的以下圖所示：

對發送方的公鑰信息進行公正步驟：（藉助第三方安全機構）

a) A和B端首先生成本身的公鑰和私鑰的密鑰對，爲了使對方能相佶本身的公鑰信息，將本身的公鑰信息告知給第三方發證機構，利用第三方機構對本身的公鑰進行公證，第三方機構會製做一個數字證書（機構編號以及發證機構的聯），而且第三方機構也要給本身設置一個合法的公鑰和私鑰，而且公鑰設爲第三方機構的公鑰證書。

b) 發證機關計箅出數字證書數據的特徵碼，並用本身的私鑰進行加密，並將加密的信息附加到特徵碼後成爲數字簽名。

c) A和B兩錠得到公正過的證書信息，並經過證書信息傳遞.獲得對方的公鑰。

d) A和B兩端與第三方機構創建鏈接，得到第三方證書，經過第三方證書得到第三方公鑰，利用第三方公鑰只要能解密數字簽名便可。

1.3.2 證書信息所包含什麼內容

目前標準的證書存儲格式是x509，還有其餘的證書格式，須要包含的內容爲：

ü 公鑰信息，以及證書過時時間

ü 證書的合法擁有人信息

ü 證書該如何被使用

ü CA頒發機構信息

ü CA簽名的校驗碼

互聯網上使用的SSL和TLS證書管理機制均使用x509的格式。

1.4 加密算法的簡介

1.4.1 對稱加密算法

對稱加密算法特性是加密和解密使用同一個密鑰，利用對稱算法能夠將明文改成密文（加密），密文還原爲明文（解密）。

對稱加密算法常見的有：

🔔 最先期的稱爲DES(Data Encryption Standard),是美國國家安全局徵集加密算法時，由一個美國公司提出的，是公開可使用的，使用的是56位的密鑰長度，可是因爲計算機的發展，可使用計算機對56位的密鑰進行暴力破解了，所以DES漸漸再也不被使用。

🔔 一種新的算法.將DES加密後，再進行一次DES加密，而後再進行一次DES ,稱爲3DES算法，是目前使用比較多的加密算法。

🔔 更安全的加密算法，AES（高級加密標準）加密算法產生.默認使用128位的加密密鑰，可是也有特殊的AES（AES192 AES256 AES512等），密鑰越長安全性提升的同時，加密效率就會下降，所以應該選擇比較合適的加密算法。

🔔 blowfish加密算法，加密不是按位進行加密的，而是將數據分紅大小相同的數據塊進行加密的。

1.4.2 單向加密算法

單向加密算法常見的有：

🔔 DH加密算法，主要用於密鑰的協商交換

🔔 MD4 MD5(128)

🔔 SHA1(160) SHA(192) SHA(256) SHA(384)

🔔 CRC-32(循環輸出校驗碼），不是加密機制，只是一種校驗機制，不提供安全性，正常加密算法是不容許出現輸入不同，輸出同樣的狀況，但CRC是能夠有這樣狀況的，由於CRC只是具備校驗功能，不具備加密功能。

單項加密算法的特徵：

🔔 數據輸入一祥，特徵碼信息輸出必然相同

🔔 雪崩效應，輸入的微小的改變，將形成輸出的巨大改變

🔔 定長輸出，不管源數據多大，但結果都是一祥的

🔔 不可逆的，沒法根據數據指紋，還原出原來的數據信息

1.4.3 非對稱加密算法

非對稱加密算法能夠實現身份認證功能（經過數字簽名實現），數據加密功能，以及現密鑰交換功能。

非對稱加密算法常見的有：

🔔 RSA,RSA既是一個公司的名稱，也是三個創始人的名稱，RSA既能夠加密又能夠進行簽名。

🔔 DSA，只能實現數字簽名功能。

🔔 ELGamal，屬於商業化的加密算法。

加密和解密須要算法來實現，所以須要主機上能夠有相應的軟件工具來控制加密和解密的算法，相應的工具就是加密和解密算法的具體實現，對稱加密算法能夠實現的工具：openssl、gpg。

OpenSSL軟件介紹

Netscape網景公司生產了最初的瀏覽器，但爲了提升瀏覽器訪問頁面的安全性，對TCP/IP模型逬行了必定改逬，在傳輸層與應用層之間，建立了一個3.5層的槪念，稱爲SSL（Secure Sockets Layer安全套接層）層，SSL不是一個軟件，只是一個庫，讓應用層將數據傳輸到傳輸層前，調用了ssl層的功能對數據進行了加密，目前比較流行的版本是（SSLv2 v3）。

因爲SSL是Netscape公司進行定義的，不夠開放性。所以爲了使加密功能更加開放，TSL（傳輸層安全協議）協議就出現了，目前比較流行的版本是（TSLv1==sslv3）, TSL更像是傳輸層上實現的數據加密。

1.5.1 OpenSSL軟件概念說明

ssl功能的開源實現，就稱爲openssl,功能很是強大，幾乎實現了市面上主流的加密算法，而且工做性能很是的好。openssl的言方連接：http://openssl.org/。

1.5.2 OpenSSL軟件組成部分

openssl是由三部分組成：

n libcrpto :通用加密庫

n libssl:TSL/SSL功能的實現，基於會話的，實現了身份認證，數據機密性和會話完整性的 TSL/SSL 庫

n openssl:提供的命令行工具，多用途命令工具，橫擬實現私有證書頒發機構；命令行工具是經過多種子命令實現openssl的相應功能

1.5.3 OpenSSL的使用

系統環境說明

[root@web01 ~]# cat /etc/redhat-release CentOS release 6.9 (Final) [root@web01 ~]# uname -r 2.6.32-696.el6.x86_64 [root@web01 ~]# sestatus SELinux status: disabled
[root@web01 ~]# /etc/init.d/iptables status
iptables: Firewall is not running.

檢查OpenSLL軟件版本：

方法一：

[root@web01 ~]# rpm -qa openssl
openssl-1.0.1e-57.el6.x86_64

方法二：

[root@web01 ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

主配置文件

/etc/pki/tls/openssl.cnf

#舉例說明，加密一個文件

# openssl enc -des3 -salt -a -in inittab -out initab.des3 <- 輸入密碼後即加密成功

# openssl enc -des3 -d -salt -a -in initab.des3 -out inittab <- 輸入密鑰後即解密成功

說明：其中命令中的salt參數，主要用於避免密碼加密後，對密鑰串的反推

md5sum inittab 
shalsum inittab
openssl dgst -shal inittab      # 利用openssl 生成文件特徵碼
                                # dgst---表示指定使用摘要命令 
                                # -shal---表示指定摘要命令選用shal算法

生成和用戶同樣的密碼串

openssl  passwd -1  # 採用md5加密用戶密碼串

生成僞隨機數方法

openssl rand -base 64 45 # 給出一個任意數字，就會生產任意的隨機數

1.5.4 OpenSSL軟件創建是有CA

ü 建立私鑰與公鑰信息

須要先給ca證書頒發機構生成證書，即生成一對密鑰；genrsa - generate an RSA private key利用gerusa生成密鑰信息。雖然只是生成私鑰，但須要清除公鑰是經過私鑰進行提取獲得的，因此只要有私鑰，就能夠有公鑰，私鑰信息是很是重要的，所以生成的私鑰文件應該是600的權限。

openssl genrsa 1024 >server.key    # 建立私鑰信息，並指定私鑰的長度爲2048，並將生成的私鑰信息保存在一個文件中
openssl genrsa -out server.key 1024 # 將私鑰信息直接進行保存，加密長度必定要放在輸出文件後面
 (umask 077;openssl genrsa -out server1024.key 1024) # 利用小括號，實現子shell功能，臨時修改umask，使之建立的私鑰文件權限爲600

說明：密鑰文件也能夠進行加密的，而且支持後期手工加密，但不建議加密，每次使用私鑰文件還要進行解密，比較麻煩
openssl rsa -in server1024.key -pubout     #讀取私鑰文件命令

ü 生成自簽署的證書

[root@web01 ~]# openssl req -new -x509 -key server1024.key -out server.crt -days 365
參數說明
req         # 用於建立新的證書
new         # 表示建立的是新的證書
x509        # 表示定義證書的格式爲標準格式
key         # 表示調用的私鑰文件信息
out         # 表示輸出證書文件信息
days        # 表示證書的有效期

生產自簽發證書的過程。

[root@web01 key]# openssl req -new -x509 -key server1024.key -out server.crt -days 3650
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN  # 定義生成證書的國家
State or Province Name (full name) []:BJ  # 定義生成證書的省份
Locality Name (eg, city) [Default City]:BJ  # 定義生成證書的城市
Organization Name (eg, company) [Default Company Ltd]:nmtui.com  # 生成證書的組織
Organizational Unit Name (eg, section) []:ops     # 生成證書的職能部門
Common Name (eg, your name or your server's hostname) []:blog.nmtui.com # 主機名稱
Email Address []:admin@nmtui.com  # 郵件地址
# 說明：此輸出信息很是重要，客戶端在獲取證書前，會利用主機名與相應服務器之間創建鏈接，而後得到證書。

查看生成證書的信息的方法

[root@web01 key]# openssl x509 -text -in server.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9747921528343358470 (0x874792fbbb49ec06)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CN, ST=BJ, L=BJ, O=nmtui.com, OU=ops, CN=blog.nmtui.com/emailAddress=admin@nmtui.com

CA目簽發證書實際建立過程

cd /etc/pki/CA/private/         # 進入到私鑰保存目錄中
(umask 077;openssl genrsa -out ./cakey.pem 2048)  #  建立一個 ca 私鑰文件
cd /etc/pki/CA                     # 進入到CA目簽發保存目錄中
openssl req -new -x509 -key private/cakey.pem -out cacert.pem # 生成自簽發證書
# 說明：因爲下面配置文件中定義了一些證書信息,因此默認便可。

ü 相關配置文件參數設定

證書頒發機構的配置文件信息設定

ca頒發機構的私鑰和證書是不能隨便放置的，而且須要配置私有頒發機構的配置文件

/etc/pki/tls/openssl.cnf

[ CA_default ] 模塊參數說明：

參數	配置	官方配置說明	解釋配置說明
dir	= /etc/pki/CA	Where everything is kept	建立並定義CA目錄信息
certs	= $dir/certs	Where the issued certs are kept	證書文件保存目錄
crl_dir	= $dir/crl	Where the issued crl are kept	證書吊銷文件保存目錄
database	= $dir/index.txt	database index file.	表示發過哪些證書，都要文件進行記錄
new_certs_dir	= $dir/newcerts	default place for new certs.	默認新證書的存放路徑
certificate	= $dir/cacert.pem	The CA certificate	定義ca機構本身的證書
serial	= $dir/serial	The current serial number	表示證書對應的序列號，通常從01開始
crlnumber	= $dir/crlnumber	the current crl number	表示吊銷證書對應的序列號
crl	= $dir/crl.pem	The current CRL	表示當前證書吊銷列表文件
private_key	= $dir/private/cakey.pem	The private key	表示ca機構自身的私鑰文件
RANDFILE	= $dir/private/.rand	private random number file	私鑰隨機數文件，此文件默認會本身創建
在/ctc/pki/CA的證書路徑下，還須要要有certs crl newcerts三個子目錄信息

指定證書相關的有效期配置

參數	配置	官方配置說明	解釋配置說明
default_days	= 365	how long to certify for	定義證書的有效期
default_crl_days	= 30	how long before next CRL	默認證書放置到吊銷列表中的保存時間
default_md	= default	use public key default MD	指定單向加密算法採用的是默認的
preserve	= no	keep passed DN ordering	-

定義[ req_distinguished_name ]模塊參數信息，即指定證書中的一些基本屬性信息

參數	配置	舉例配置	解釋配置說明
countryName_default	= XX	= CN	國家或地區
stateOrProvinceName_default	= Default Province	= BJ	省份/州
localityName_default	= Default City	= BJ	城市名稱
0.organizationName_default	= Default Company Ltd	= nmtui.com	公司組織名稱
organizationalUnitName_default	=	= ops	部門名稱
commonName_default	-	= blog.nmtui.com	主機名/域名
emailAddress_default	-	= admin@nmtui.com	郵件地址

1.5.5 公司中申請證書文件的流程

# 第一步建立私鑰文件：
 (umask 077;openssl genrsa -out httpd.key 1024)        # 模擬客戶端，建立web服務的私鑰
# 第二步建立證書請求文件
openssl req -new -key httpd.key -out httpd.csr        # 建立向CA申請證書的請求證書
# 第三步將請求文件發送給證書頒發機構

1.6 WEB服務實現HTTPS訪問

1.6.1 證書的建立

說明：再測試環境中，可使用只生產的證書進行測試（使用只生產的證書在訪問時會報證書不安全！），自生產證書的方法如上所示。

這是使用的時騰訊雲申請的免費SSL證書進行測試。

證書獲取方法：

登錄騰訊雲，訪問https://console.cloud.tencent.com/ssl證書管理。

圖 - 申請證書

圖 - 選擇《亞洲誠信》免費證書

圖 - 輸入域名信息

注意：域名須要爲你所持有的域名

圖 - 驗證域名的全部權

域名驗證經過後，便可下載生成的密鑰

圖 - 下載證書文件

圖 - 獲得的證書文件

1.6.2 nginx配置https訪問

nginx的搭建參考：http://www.cnblogs.com/clsn/p/8025324.html

建立證書存放目錄，講獲取的證書放到這個目錄

[root@web01 key]# mkdir -p cd /application/nginx/conf/key/
[root@web01 ~]# cd /application/nginx/conf/key/
[root@web01 key]# ll 
total 8
-rw-r--r-- 1 www www 3307 Jan 18 10:48 1_blog.nmtui.com_bundle.crt
-rw-r--r-- 1 www www 1700 Jan 18 10:48 2_blog.nmtui.com.key

主配置文件

[root@web01 ~]# cat /application/nginx/conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    client_max_body_size 1000M;
    client_body_buffer_size 10M;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    include extra/blog.conf;
}

blog站點配置文件

[root@web01 ~]# cat /application/nginx/conf/extra/blog.conf 
    server{
        listen       80;
        server_name  blog.nmtui.com;
        rewrite ^(.*) https://$host$1 permanent;
    }
    server {
        listen       443;
        server_name  blog.nmtui.com;
        ssl on;
        ssl_certificate /application/nginx/conf/key/1_blog.nmtui.com_bundle.crt;
        ssl_certificate_key /application/nginx/conf/key/2_blog.nmtui.com.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
        ssl_prefer_server_ciphers on;
        location / {
            root   html/blog;
            try_files $uri $uri/ /index.php?$args;
            index  index.php index.html index.htm;
    }
       rewrite /wp-admin$ $scheme://$host$uri/ permanent;     
       location ~* .*\.(php|php5)?$ {
                    root html/blog;
                    fastcgi_pass  127.0.0.1:9000;
                    fastcgi_index index.php;
                    include fastcgi.conf;
        }
        access_log  logs/access_blog.log  main;
    }

建立測試面頁

[root@web01 ~]# cat >> /application/nginx/html/blog/clsn.html <<EOF
web01
https://blog.nmtui.com
EOF

配置完成後重啓，在瀏覽器進訪問測試

1.6.3 實現http訪問自動跳轉到https的方法

方法一：利用地址重寫功能

server {
    listen  80;
    server_name blog.nmtui.com;
    rewrite ^(.*)$  https://$host$1 permanent;
}
# 說明：在https配置server基礎上再添加http跳轉server

方法二：利用error_page識別錯誤碼信息進行跳轉

server {
        listen       443;
        listen       80;
        server_name  blog.nmtui.com;
        ssl on;
        ssl_certificate /application/nginx/conf/key/1_blog.nmtui.com_bundle.crt;
        ssl_certificate_key /application/nginx/conf/key/2_blog.nmtui.com.key;
        location / {
            root   html/www;
            index  index.html index.htm;
        }
       error_page 497  https://$host$uri;
}

說明：497爲內置錯誤碼，當訪問http沒法處理，須要利用https處理時

1.6.4 利用nginx反向代理服務器進行http到https跳轉

第一個里程碑：修改地址池信息

upstream www_server_pools {
                server 10.0.0.8:443;
    }

第二個里程碑：修改地址池調用信息

server {
        listen 443;
        server_name blog.nmtui.com;
        ssl on;
        ssl_certificate /application/nginx/conf/key/1_blog.nmtui.com_bundle.crt;
        ssl_certificate_key /application/nginx/conf/key/2_blog.nmtui.com.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
        ssl_prefer_server_ciphers on;
        location / {
            proxy_pass https://server_pools;
        }
    }

第三個里程碑：定義http到https跳轉配置信息

server {
        listen       80;
        server_name  blog.nmtui.com;
        rewrite ^(.*)$  https://$host$1 permanent;
    }

1.7 附錄 - ngx_http_ssl_module模塊說明

ngx_http_ssl_module模塊爲實現 HTTPS提供了必要的支持。

此模塊不是在默認狀況下生成的, 在安裝nginx時使用--with-http_ssl_module配置參數啓用它。此模塊須要OpenSSL庫。詳情參照：http://www.cnblogs.com/clsn/p/8025324.html#_label3

1.7.1 示例配置

爲了減輕處理器負載，建議

ü 設置工做進程的數量等於處理器的數量；

ü 啓用保持鏈接；

ü 啓用共享會話緩存；

ü 禁用內置的會話緩存；

ü 建議增長會話超時時間（默認爲5分鐘）。

worker_processes auto;

http {

    ...

    server {
        listen              443 ssl;
        keepalive_timeout   70;

        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
        ssl_certificate     /usr/local/nginx/conf/cert.pem;
        ssl_certificate_key /usr/local/nginx/conf/cert.key;
        ssl_session_cache   shared:SSL:10m;
        ssl_session_timeout 10m;

        ...
    }

1.7.2 SSL模塊指令說明

1.7.2.1 ssl

Syntax:    ssl on | off;
Default:    ssl off;
Context:    http, server

爲指定的虛擬服務器啓用HTTPS協議，默認關閉。

1.7.2.2 ssl_buffer_size

Syntax:    ssl_buffer_size size;
Default:    ssl_buffer_size 16k;
Context:    http, server
# This directive appeared in version 1.5.9.

該指令用於設置用於發送數據的緩衝區的大小。

默認狀況下，緩衝區大小爲16k，這對應於發送大響應時的最小開銷。爲了將發送第一個字節的時間減小，可使用較小的值，例如：

ssl_buffer_size 4k;

1.7.2.3 ssl_certificate

Syntax:    ssl_certificate file;
Default:    —
Context:    http, server

指定虛擬主機的 PEM 格式的證書文件路徑。若是除了主證書外,還要指定中間證書, 則應按如下順序在同一文件中指定它們: 主證書首先出現, 而後是中間證書。PEM 格式的密鑰能夠放在同一個文件中。

從1.11.0版本開始，能夠屢次使用該指令來加載不一樣類型的證書，例如RSA和ECDSA：

server {
    listen              443 ssl;
    server_name         example.com;

    ssl_certificate     example.com.rsa.crt;
    ssl_certificate_key example.com.rsa.key;

    ssl_certificate     example.com.ecdsa.crt;
    ssl_certificate_key example.com.ecdsa.key;

    ...
}

注意：只有OpenSSL 1.0.2及以上版本，支持加載不一樣類型的證書。對於較舊的版本，只能使用同一類型的單個證書。

注意：使用nginx配置HTTPS多虛擬主機時，不一樣的主機要監聽不一樣的地址，不然在初次訪問時，SSL鏈接在瀏覽器發送HTTPs請求以前創建，而nginx不知道請求的服務器的名稱。所以，它只能提供默認的服務器證書。將會致使業務的異常。詳情參照：http://nginx.org/en/docs/http/configuring_https_servers.html#name_based_https_servers

1.7.2.4 ssl_certificate_key

Syntax:    ssl_certificate_key file;
Default:    —
Context:    http, server

指定虛擬主機的 PEM 格式的密鑰文件存放路徑。

在1.7.9版本engine:name:id 能夠指定替代密鑰文件，該指令可以從OpenSSL中加載指定ID的密鑰 name。

1.7.2.5 ssl_ciphers

Syntax:    ssl_ciphers ciphers;
Default:    ssl_ciphers HIGH:!aNULL:!MD5;
Context:    http, server

指定證書的加密方式。加密方式要是openssl能夠識別的方式，例如：

ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

全部的加密方式能夠在系統中經過openssl ciphers命令查看。

選用加密方式時要注意不一樣版本之間的兼容性問題，詳情參考http://nginx.org/en/docs/http/configuring_https_servers.html#compatibility

1.7.2.6 ssl_client_certificate

Syntax:    ssl_client_certificate file;
Default:    —
Context:    http, server

若是啓用了ssl_stapling，則須要指定PEM格式的可信CA證書文件路徑，用於驗證客戶端證書和OCSP(Online Certificate Status Protocol，在線證書狀態協議)響應。

注意:使用該參數時證書列表將被髮送給客戶。若是不須要，可使用ssl_trusted_certificate 指令。

1.7.2.7 ssl_crl

Syntax:    ssl_crl file;
Default:    —
Context:    http, server
# This directive appeared in version 0.8.7.

指定用於驗證客戶端證書的 PEM 格式指定具備吊銷證書 (CRL) 的文件。

1.7.2.8 ssl_dhparam

Syntax:    ssl_dhparam file;
Default:    —
Context:    http, server
# This directive appeared in version 0.7.2.

指定DHE加密方式的DH證書文件位置。

1.7.2.9 ssl_ecdh_curve

Syntax:    ssl_ecdh_curve curve;
Default:    
ssl_ecdh_curve auto;
Context:    http, server
# This directive appeared in versions 1.1.0 and 1.0.6.

指定一個curve用於ECDHE密碼。

當使用的OpenSSL 1.0.2或更高版本時，能夠指定多curve（1.11.0），例如：

ssl_ecdh_curve prime256v1:secp384r1;

特殊值auto（1.11.0）指示nginx在使用OpenSSL 1.0.2或更高版本時使用OpenSSL庫中內置的列表爲prime256v1，或使用舊版本。

在版本1.11.0 以前, 默認curve爲prime256v1。

1.7.2.10 ssl_password_file

Syntax:    ssl_password_file file;
Default:    —
Context:    http, server
# This directive appeared in version 1.7.3.

爲密鑰指定一個密碼文件 , 其中每一個口令都在單獨的行上指定密碼。密碼在加載密鑰時依次嘗試。

示例：

http {
    ssl_password_file /etc/keys/global.pass;
    ...

    server {
        server_name www1.example.com;
        ssl_certificate_key /etc/keys/first.key;
    }

    server {
        server_name www2.example.com;

        # named pipe can also be used instead of a file
        ssl_password_file /etc/keys/fifo;
        ssl_certificate_key /etc/keys/second.key;
    }
}

1.7.2.11 ssl_prefer_server_ciphers

Syntax:    ssl_prefer_server_ciphers on | off;
Default:    ssl_prefer_server_ciphers off;
Context:    http, server

指定在使用 SSLv3 和 TLS 協議時, 服務器密碼應優先於客戶端密碼。

1.7.2.12 ssl_protocols

Syntax:    ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];
Default:    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Context:    http, server

啓用指定的SSL協議。

說明：

TLSv1.1和 TLSv1.2參數 (1.1.1三、1.0.12) 僅在使用 OpenSSL 1.0.1 或更高時才起做用。
TLSv1.3參數 (1.13.0) 僅在使用用 TLSv1.3 僅在使用 OpenSSL 1.1.1 時有效。

1.7.2.13 ssl_session_cache

Syntax:    ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
Default:    ssl_session_cache none;
Context:    http, server

設置存儲會話參數的高速緩存的類型和大小。緩存能夠是如下任何一種類型：

類型	類型說明
off	嚴格禁止使用會話緩存: nginx 會明確告訴客戶端會話可能沒法重用。
none	不容許使用會話緩存: nginx 告訴客戶端會話能夠重用, 但實際上不會將會話參數存儲在緩存中。
builtin	創建 OpenSSL 的緩存：僅由一個工做進程使用。緩存大小在會話中指定。若是未給定大小, 則默認爲20480個會話。注意：使用內置緩存會致使產生內存碎片。
shared	全部工做進程之間共享的緩存：緩存大小以字節爲單位指定，一兆字節能夠存儲大約4000個會話。每一個共享緩存都應具備名稱。能夠在多個虛擬服務器中使用同名的緩存。

兩種不一樣的緩存類型均可以同時使用, 例如:

ssl_session_cache builtin:1000 shared:SSL:10m;

可是, 在沒有內置緩存的狀況下使用共享緩存纔會更有效。

1.7.2.14 ssl_session_ticket_key

Syntax:    ssl_session_ticket_key file;
Default:    —
Context:    http, server
# This directive appeared in version 1.5.7.

指定用於加密和解密TLS會話令牌的密鑰文件存放位置。若是須要在多個服務器之間共享相同的密鑰,則須要使用該指令。默認狀況下, 使用隨機生成的密鑰。

若是指定了多個密鑰, 則僅使用第一個密鑰對 TLS 會話進行加密。密鑰對時能夠進行輪換的，例如：

ssl_session_ticket_key current.key;
ssl_session_ticket_key previous.key;

該文件必須包含80或48字節的隨機數, 可使用如下命令進行建立：

openssl rand 80 > ticket.key

根據文件大小的不一樣, AES256 (對於80字節密鑰、1.11.8) 或 AES128 (對於48字節密鑰) 用於加密。

1.7.2.15 ssl_session_tickets

Syntax:    ssl_session_tickets on | off;
Default:    ssl_session_tickets on;
Context:    http, server
# This directive appeared in version 1.5.9.

經過TLS session tickets啓用或禁用會話恢復。詳情參考：https://tools.ietf.org/html/rfc5077

1.7.2.16 ssl_session_timeout

Syntax:    ssl_session_timeout time;
Default:    ssl_session_timeout 5m;
Context:    http, server

指定客戶端能夠重用會話參數的時間。

1.7.2.17 ssl_stapling

Syntax:    ssl_stapling on | off;
Default:    ssl_stapling off;
Context:    http, server
# This directive appeared in version 1.3.7.

啓用或禁用服務器對OSCP的響應，詳情參考：https://tools.ietf.org/html/rfc4366#section-3.6

配置示例：

ssl_stapling on;
resolver 192.0.2.1;

要使 OCSP 正常工做, 須要知道服務器證書頒發者的證書

若是ssl_certificate文件不包含中間證書, 則應在ssl_trusted_certificate文件中顯示服務器證書頒發者的證書。

對於 OCSP 響應方主機名的解析, 還應指定解析程序指令。

1.7.2.18 ssl_stapling_file

Syntax:    ssl_stapling_file file;
Default:    —
Context:    http, server
# This directive appeared in version 1.3.7.

設置後，將從指定的file中採起訂閱的 ocsp 響應, 而不是查詢在服務器證書中指定的 ocsp 應答器。

該文件應該是由「 openssl ocsp」命令產生的DER格式。

1.7.2.19 ssl_stapling_responder

Syntax:    ssl_stapling_responder url;
Default:    —
Context:    http, server
# This directive appeared in version 1.3.7.

重寫在 "頒發機構信息訪問" 證書擴展中指定的 OCSP 響應程序的 URL。

參考文獻：https://tools.ietf.org/html/rfc5280#section-4.2.2.1

僅支持 "http://" OCSP 響應程序，例如:

ssl_stapling_responder http://ocsp.example.com/;

1.7.2.20 ssl_stapling_verify

Syntax:    ssl_stapling_verify on | off;
Default:    ssl_stapling_verify off;
Context:    http, server
# This directive appeared in version 1.3.7.

啓用或禁用服務器對 OCSP 響應的驗證。

要進行驗證, 應使用ssl_trusted_certificate指令將服務器證書頒發者、根證書和全部中間證書的證書配置爲受信任。

1.7.2.21 ssl_trusted_certificate

Syntax:    ssl_trusted_certificate file;
Default:    —
Context:    http, server
# This directive appeared in version 1.3.7.

指定一個 PEM 格式的文件 , 其中帶有用於驗證 ssl_stapling啓用時使用的校驗證書和 OCSP 進行驗證。

與ssl_client_certificate設置的證書正好相反, 這些證書的列表將不會發送到客戶端。

1.7.2.22 ssl_verify_client

Syntax:    ssl_verify_client on | off | optional | optional_no_ca;
Default:    ssl_verify_client off;
Context:    http, server

啓用對客戶端證書的驗證。驗證結果存儲在 $ssl_client_verify變量中。

可選參數optional（0.8.7+）請求客戶端證書、驗證證書是否存在。

可選參數optional_no_ca (1.3.8, 1.2.5)請求客戶端證書而不須要將簽署由受信任的CA證書。這適用於nginx外部的服務運行實際證書驗證的狀況。證書的內容能夠經過變量$ssl_client_cert進行訪問。

1.7.2.23 ssl_verify_depth

Syntax:    ssl_verify_depth number;
Default:    ssl_verify_depth 1;
Context:    http, server

設置客戶端證書的驗證深度。

1.7.3 ngx_http_ssl_module模塊中常見錯誤處理

在ngx_http_ssl_module模塊支持幾種非標準錯誤代碼, 可用於使用error_page指令進行重定向。

錯誤代碼	產生緣由
495	an error has occurred during the client certificate verification; 在客戶端證書驗證過程當中發生錯誤;
496	a client has not presented the required certificate; 客戶未出示所需證書;
497	a regular request has been sent to the HTTPS port. 常規請求已發送到HTTPS端口。

在對請求進行了徹底分析而且變量 (如$request_uri、 $uri、 $args和其餘項) 可用以後, 重定向發生。

1.7.4 ngx_http_ssl_module模塊中嵌入變量

ngx_http_ssl_module模塊支持多個嵌入變量：

變量	變量說明
$ssl_cipher	返回用於已創建的 SSL 鏈接的密碼字符串;
$ssl_ciphers	返回客戶端支持的密碼列表（1.11.7）。
$ssl_client_escaped_cert	以 PEM 格式 (urlencoded) 返回已創建的 SSL 鏈接 (1.13.5) 的客戶端證書。
$ssl_client_cert	以創建的SSL鏈接的PEM格式返回客戶端證書，除第一行以外的每一行都加上製表符; 這是爲了在proxy_set_header指令中使用; 該變量已被棄用，$ssl_client_escaped_cert應該使用該變量。
$ssl_client_fingerprint	爲創建的SSL鏈接（1.7.1）返回客戶端證書的SHA1指紋;
$ssl_client_i_dn	根據RFC 2253 (1.11.6) 返回已創建的 SSL 鏈接的客戶端證書的 "頒發者 DN" 字符串;
$ssl_client_i_dn_legacy	返回已創建的 SSL 鏈接的客戶端證書的 "頒發者 DN" 字符串; 在版本1.11.6 以前, 變量名爲$ssl_client_i_dn.
$ssl_client_raw_cert	以 PEM 格式返回已創建的 SSL 鏈接的客戶端證書;
$ssl_client_s_dn	根據RFC 2253（1.11.6），爲創建的SSL鏈接返回客戶端證書的「主題DN」字符串 ;
$ssl_client_s_dn_legacy	爲創建的SSL鏈接返回客戶端證書的「主題DN」字符串; 在版本1.11.6以前，變量名是$ssl_client_s_dn
$ssl_client_serial	爲創建的SSL鏈接返回客戶端證書的序列號;
$ssl_client_v_end	返回客戶端證書的結束日期（1.11.7）;
$ssl_client_v_remain	返回客戶端證書過時的天數（1.11.7）;
$ssl_client_v_start	返回客戶端證書的開始日期（1.11.7）;
$ssl_client_verify	若是證書不存在，則返回客戶端證書驗證的結果：「 SUCCESS」，「 FAILED:reason」和「 NONE」; 在版本1.11.7以前，「 FAILED」結果不包含reason字符串。
$ssl_curves	返回由客戶端 (1.11.7) 支持的curves 僅當使用 OpenSSL 版本1.0.2 或更高時, 才支持該變量。
$ssl_protocol	返回已創建的 SSL 鏈接的協議;
$ssl_server_name	經過SNI （1.7.0）返回請求的服務器名稱 ;
$ssl_session_id	返回創建的SSL鏈接的會話標識符;
$ssl_session_reused	若是從新使用了 SSL 會話, 則返回 "r", 不然爲 "." (1.5.11)。