https認證過程

『壹』 https建立連接的的過程是怎麼樣的

HTTPS基本原理
一、http為什麼不安全？
http協議沒有任何的加密以及身份驗證的機制，非常容易遭遇竊聽、劫持、篡改，因此會造成個人隱私泄露，惡意的流量劫持等嚴重的安全問題。

國外很多網站都支持了全站https，國內方面目前網路已經在年初完成了搜索的全站https，其他大型的網站也在跟進中，網路最先完成全站https的最大原因就是網路作為國內最大的流量入口，劫持也必然是首當其沖的，造成的有形的和無形的損失也就越大。關於流量劫持問題，我在另一篇文章中也有提到，基本上是互聯網企業的共同難題，https也是目前公認的比較好的解決方法。但是https也會帶來很多性能以及訪問速度上的犧牲，很多互聯網公司在做大的時候都會遇到這個問題：https成本高，速度又慢，規模小的時候在涉及到登錄和交易用上就夠了，做大以後遇到信息泄露和劫持，想整體換，代價又很高。
2、https如何保證安全
要解決上面的問題，就要引入加密以及身份驗證的機制。

這時我們引入了非對稱加密的概念，我們知道非對稱加密如果是公鑰加密的數據私鑰才能解密，所以我只要把公鑰發給你，你就可以用這個公鑰來加密未來我們進行數據交換的秘鑰，發給我時，即使中間的人截取了信息，也無法解密，因為私鑰在我這里，只有我才能解密，我拿到你的信息後用私鑰解密後拿到加密數據用的對稱秘鑰，通過這個對稱密鑰來進行後續的數據加密。除此之外，非對稱加密可以很好的管理秘鑰，保證每次數據加密的對稱密鑰都是不相同的。
但是這樣似乎還不夠，如果中間人在收到我的給你公鑰後並沒有發給你，而是自己偽造了一個公鑰發給你，這是你把對稱密鑰用這個公鑰加密發回經過中間人，他可以用私鑰解密並拿到對稱密鑰，此時他在把此對稱密鑰用我的公鑰加密發回給我，這樣中間人就拿到了對稱密鑰，可以解密傳輸的數據了。為了解決此問題，我們引入了數字證書的概念。我首先生成公私鑰，將公鑰提供給相關機構（CA），CA將公鑰放入數字證書並將數字證書頒布給我，此時我就不是簡單的把公鑰給你，而是給你一個數字證書，數字證書中加入了一些數字簽名的機制，保證了數字證書一定是我給你的。

所以綜合以上三點： 非對稱加密演算法（公鑰和私鑰）交換秘鑰 + 數字證書驗證身份（驗證公鑰是否是偽造的） + 利用秘鑰對稱加密演算法加密數據 = 安全

3、https協議簡介
為什麼是協議簡介呢？因為https涉及的東西實在太多了，尤其是一些加密演算法，非常的復雜，對於這些演算法面的東西就不去深入研究了，這部分僅僅是梳理一下一些關於https最基本的原理，為後面分解https的連接建立以及https優化等內容打下理論基礎。
3.1 對稱加密演算法
對稱加密是指加密和解密使用相同密鑰的加密演算法。它要求發送方和接收方在安全通信之前，商定一個密鑰。對稱演算法的安全性依賴於密鑰，泄漏密鑰就意味著任何人都可以對他們發送或接收的消息解密，所以密鑰的保密性對通信至關重要。
對稱加密又分為兩種模式：流加密和分組加密。
流加密是將消息作為位流對待，並且使用數學函數分別作用在每一個位上，使用流加密時，每加密一次，相同的明文位會轉換成不同的密文位。流加密使用了密鑰流生成器，它生成的位流與明文位進行異或，從而生成密文。現在常用的就是RC4，不過RC4已經不再安全，微軟也建議網路盡量不要使用RC4流加密。
分組加密是將消息劃分為若干位分組，這些分組隨後會通過數學函數進行處理，每次一個分組。假設需要加密發生給對端的消息，並且使用的是64位的分組密碼，此時如果消息長度為640位，就會被劃分成10個64位的分組，每個分組都用一系列數學公式公式進行處理，最後得到10個加密文本分組。然後，將這條密文消息發送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的演算法解密，最終得到明文的消息。比較常用的分組加密演算法有DES、3DES、AES。其中DES是比較老的加密演算法，現在已經被證明不安全。而3DES是一個過渡的加密演算法，相當於在DES基礎上進行三重運算來提高安全性，但其本質上還是和DES演算法一致。而AES是DES演算法的替代演算法，是現在最安全的對稱加密演算法之一。分組加密演算法除了演算法本身外還存在很多種不同的運算方式，比如ECB、CBC、CFB、OFB、CTR等，這些不同的模式可能只針對特定功能的環境中有效，所以要了解各種不同的模式以及每種模式的用途。這個部分後面的文章中會詳細講。
對稱加密演算法的優、缺點：
優點：演算法公開、計算量小、加密速度快、加密效率高。
缺點：（1）交易雙方都使用同樣鑰匙，安全性得不到保證；
（2）每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增長，密鑰管理成為用戶的負擔。
（3）能提供機密性，但是不能提供驗證和不可否認性。
3.2 非對稱加密演算法
在非對稱密鑰交換演算法出現以前，對稱加密一個很大的問題就是不知道如何安全生成和保管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使得對稱密鑰的生成和使用更加安全。
密鑰交換演算法本身非常復雜，密鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等操作。
常見的密鑰交換演算法有RSA，ECDHE，DH，DHE等演算法。涉及到比較復雜的數學問題，下面就簡單介紹下最經典的RSA演算法。RSA：演算法實現簡單，誕生於1977年，歷史悠久，經過了長時間的破解測試，安全性高。缺點就是需要比較大的素數也就是質數（目前常用的是2048位）來保證安全強度，很消耗CPU運算資源。RSA是目前唯一一個既能用於密鑰交換又能用於證書簽名的演算法。我覺得RSA可以算是最經典的非對稱加密演算法了，雖然演算法本身都是數學的東西，但是作為最經典的演算法，我自己也花了點時間對演算法進行了研究，後面會詳細介紹。
非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：
1，CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。
2，非對稱加密演算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味著待加密內容不能超過256個位元組。
所以公鑰加密（極端消耗CPU資源）目前只能用來作密鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。

3.3 身份認證
https協議中身份認證的部分是由數字證書來完成的，證書由公鑰、證書主體、數字簽名等內容組成，在客戶端發起SSL請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證（驗證查看這張證書是否是偽造的？也就是公鑰是否是偽造的），並獲取用於秘鑰交換的非對稱密鑰（獲取公鑰）。
數字證書有兩個作用：
1，身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。
2，分發公鑰。每個數字證書都包含了注冊者生成的公鑰（驗證確保是合法的，非偽造的公鑰）。在SSL握手時會通過certificate消息傳輸給客戶端。
申請一個受信任的數字證書通常有如下流程：
1，終端實體（可以是一個終端硬體或者網站）生成公私鑰和證書請求。
2，RA（證書注冊及審核機構）檢查實體的合法性。如果個人或者小網站，這一步不是必須的。
3，CA（證書簽發機構）簽發證書，發送給申請者。
4，證書更新到repository（負責數字證書及CRL內容存儲和分發），終端後續從repository更新證書，查詢證書狀態等。
數字證書驗證：
申請者拿到CA的證書並部署在網站伺服器端，那瀏覽器發起握手接收到證書後，如何確認這個證書就是CA簽發的呢？怎樣避免第三方偽造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防偽標簽，目前使用最廣泛的SHA-RSA（SHA用於哈希演算法，RSA用於非對稱加密演算法）數字簽名的製作和驗證過程如下：
1，數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，然後使用CA自己的私鑰對消息摘要進行加密。
2，數字簽名的校驗。使用CA的公鑰解密簽名，然後使用相同的簽名函數對待簽名證書內容進行簽名並和服務端數字簽名里的簽名內容進行比較，如果相同就認為校驗成功。

需要注意的是：
1）數字簽名簽發和校驗使用的密鑰對是CA自己的公私密鑰，跟證書申請者提交的公鑰沒有關系。
2）數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。
3）現在大的CA都會有證書鏈，證書鏈的好處一是安全，保持根CA的私鑰離線使用。第二個好處是方便部署和撤銷，即如果證書出現問題，只需要撤銷相應級別的證書，根證書依然安全。
4）根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的製作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。
5）怎樣獲取根CA和多級CA的密鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和操作系統都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統環境里。
3.4 數據完整性驗證
數據傳輸過程中的完整性使用MAC演算法來保證。為了避免網路中傳輸的數據被非法篡改，SSL利用基於MD5或SHA的MAC演算法來保證消息的完整性。 MAC演算法是在密鑰參與下的數據摘要演算法，能將密鑰和任意長度的數據轉換為固定長度的數據。發送者在密鑰的參與下，利用MAC演算法計算出消息的MAC值，並將其加在消息之後發送給接收者。接收者利用同樣的密鑰和MAC演算法計算出消息的MAC值，並與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。 由於MD5在實際應用中存在沖突的可能性比較大，所以盡量別採用MD5來驗證內容一致性。SHA也不能使用SHA0和SHA1，中國山東大學的王小雲教授在2005年就宣布破解了 SHA-1完整版演算法。微軟和google都已經宣布16年及17年之後不再支持sha1簽名證書。MAC演算法涉及到很多復雜的數學問題，這里就不多講細節了。

專題二--【實際抓包分析】

抓包結果：
fiddler：

wireshark:

可以看到，網路和我們公司一樣，也採用以下策略：
（1）對於高版本瀏覽器，如果支持 https，且加解密演算法在TLS1.0 以上的，都將所有 http請求重定向到 https請求
（2）對於https請求，則不變。

【以下只解讀https請求】
1、TCP三次握手

可以看到，我們訪問的是 http://www..com/ ， 在初次建立 三次握手的時候， 用戶是去 連接 8080埠的（因為公司辦公網做了代理，因此，我們實際和代理機做的三次握手，公司代理機再幫我們去連接網路伺服器的80埠）

2、CONNECT 建立
由於公司辦公網訪問非騰訊域名，會做代理，因此，在進行https訪問的時候，我們的電腦需要和公司代理機做 " CONNECT " 連接（關於 " CONNECT " 連接， 可以理解為雖然後續的https請求都是公司代理機和網路伺服器進行公私鑰連接和對稱秘鑰通信，但是，有了 " CONNECT " 連接之後，可以認為我們也在直接和網路伺服器進行公私鑰連接和對稱秘鑰通信。 ）

fiddler抓包結果：

CONNECT之後， 後面所有的通信過程，可以看做是我們的機器和網路伺服器在直接通信

3、 client hello
整個 Secure Socket Layer只包含了： TLS1.2 Record Layer內容

（1）隨機數
在客戶端問候中，有四個位元組以Unix時間格式記錄了客戶端的協調世界時間（UTC）。協調世界時間是從1970年1月1日開始到當前時刻所經歷的秒數。在這個例子中，0x2516b84b就是協調世界時間。在他後面有28位元組的隨機數（ random_C ），在後面的過程中我們會用到這個隨機數。

（2）SID（Session ID）
如果出於某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把。
因為我們抓包的時候，是幾個小時內第一次訪問 https://www.bao.com 首頁，因此，這里並沒有 Session ID. （稍會兒我們會看到隔了半分鍾，第二次抓包就有這個Session ID）
session ID是目前所有瀏覽器都支持的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果客戶端的請求發到另一台伺服器，就無法恢復對話。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。

（3） 密文族（Cipher Suites）：
RFC2246中建議了很多中組合，一般寫法是"密鑰交換演算法-對稱加密演算法-哈希演算法，以「TLS_RSA_WITH_AES_256_CBC_SHA」為例：
（a） TLS為協議，RSA為密鑰交換的演算法；
（b） AES_256_CBC是對稱加密演算法（其中256是密鑰長度，CBC是分組方式）；
（c） SHA是哈希的演算法。
瀏覽器支持的加密演算法一般會比較多，而服務端會根據自身的業務情況選擇比較適合的加密組合發給客戶端。（比如綜合安全性以及速度、性能等因素）
（4） Server_name擴展：（ 一般瀏覽器也支持 SNI（Server Name Indication））
當我們去訪問一個站點時，一定是先通過DNS解析出站點對應的ip地址，通過ip地址來訪問站點，由於很多時候一個ip地址是給很多的站點公用，因此如果沒有server_name這個欄位，server是無法給與客戶端相應的數字證書的，Server_name擴展則允許伺服器對瀏覽器的請求授予相對應的證書。

還有一個很好的功能： SNI（Server Name Indication）。這個的功能比較好，為了解決一個伺服器使用多個域名和證書的SSL/TLS擴展。一句話簡述它的工作原理就是，在連接到伺服器建立SSL連接之前先發送要訪問站點的域名（Hostname），這樣伺服器根據這個域名返回一個合適的CA證書。目前，大多數操作系統和瀏覽器都已經很好地支持SNI擴展，OpenSSL 0.9.8已經內置這一功能，據說新版的nginx也支持SNI。）
4、 伺服器回復（包括 Server Hello， Certificate， Certificate Status）
伺服器在收到client hello後，會回復三個數據包,下面分別看一下：
1）Server Hello

1、我們得到了伺服器的以Unix時間格式記錄的UTC和28位元組的隨機數 （random_S）。
2、Seesion ID，服務端對於session ID一般會有三種選擇 （稍會兒我們會看到隔了半分鍾，第二次抓包就有這個Session ID） ：
1）恢復的session ID：我們之前在client hello裡面已經提到，如果client hello裡面的session ID在服務端有緩存，服務端會嘗試恢復這個session；
2）新的session ID：這里又分兩種情況，第一種是client hello裡面的session ID是空值，此時服務端會給客戶端一個新的session ID，第二種是client hello裡面的session ID此伺服器並沒有找到對應的緩存，此時也會回一個新的session ID給客戶端；
3）NULL：服務端不希望此session被恢復，因此session ID為空。
3、我們記得在client hello裡面，客戶端給出了21種加密族，而在我們所提供的21個加密族中，服務端挑選了「TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256」。
（a） TLS為協議，RSA為密鑰交換的演算法；
（b） AES_256_CBC是對稱加密演算法（其中256是密鑰長度，CBC是分組方式）；
（c） SHA是哈希的演算法。
這就意味著服務端會使用ECDHE-RSA演算法進行密鑰交換，通過AES_128_GCM對稱加密演算法來加密數據，利用SHA256哈希演算法來確保數據完整性。這是網路綜合了安全、性能、訪問速度等多方面後選取的加密組合。

2）Certificate

在前面的https原理研究中，我們知道為了安全的將公鑰發給客戶端，服務端會把公鑰放入數字證書中並發給客戶端（數字證書可以自簽發，但是一般為了保證安全會有一個專門的CA機構簽發），所以這個報文就是數字證書，4097 bytes就是證書的長度。
我們打開這個證書，可以看到證書的具體信息，這個具體信息通過抓包報文的方式不是太直觀，可以在瀏覽器上直接看。 （點擊 chrome 瀏覽器 左上方的 綠色 鎖型按鈕）

3）Server Hello Done
我們抓的包是將 Server Hello Done 和 server key exchage 合並的包：

4）客戶端驗證證書真偽性
客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：
證書鏈的可信性trusted certificate path，方法如前文所述；
證書是否吊銷revocation，有兩類方式離線CRL與在線OCSP，不同的客戶端行為會不同；
有效期expiry date，證書是否在有效時間范圍；
域名domain，核查證書域名是否與當前的訪問域名匹配，匹配規則後續分析；

5）秘鑰交換

這個過程非常復雜，大概總結一下：

（1）首先，其利用非對稱加密實現身份認證和密鑰協商，利用非對稱加密，協商好加解密數據的 對稱秘鑰（外加CA認證，防止中間人竊取 對稱秘鑰）
（2）然後，對稱加密演算法採用協商的密鑰對數據加密，客戶端和伺服器利用 對稱秘鑰 進行通信；
（3）最後，基於散列函數驗證信息的完整性，確保通信數據不會被中間人惡意篡改。

此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數random_C和random_S與自己計算產生的Pre-master（由客戶端和伺服器的 pubkey生成的一串隨機數），計算得到協商對稱密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)

6）生成 session ticket

如果出於某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把。
因為我們抓包的時候，是幾個小時內第一次訪問 https://www.bao.com 首頁，因此，這里並沒有 Session ID. （稍會兒我們會看到隔了半分鍾，第二次抓包就有這個Session ID）
session ID是目前所有瀏覽器都支持的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果客戶端的請求發到另一台伺服器，就無法恢復對話。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。
後續建立新的https會話，就可以利用 session ID 或者 session Tickets ， 對稱秘鑰可以再次使用，從而免去了 https 公私鑰交換、CA認證等等過程，極大地縮短 https 會話連接時間。

7） 利用對稱秘鑰傳輸數據

【半分鍾後，再次訪問網路】：
有這些大的不同：

由於伺服器和瀏覽器緩存了 Session ID 和 Session Tickets，不需要再進行 公鑰證書傳遞，CA認證，生成 對稱秘鑰等過程，直接利用半分鍾前的 對稱秘鑰 加解密數據進行會話。
1）Client Hello

2）Server Hello

『貳』 如何申請https證書最好能給個詳細的步驟流程什麼的

申請https證書對於新手來說是有點復雜的，可以參考一下的流程：

第一步：將回CSR提交到代理商答

CSR(Certificate Signing Request)文件必須由用戶自己生成，也可以利用在線CSR生成工具。選擇要申請的產品，提交一個新的訂單，並將製作好的CSR文件提交。

第二步 資料提交到CA

當收到您的訂單和CSR後，如果是域名驗證型證書(DV SSL證書)，在域名驗證之後10分鍾左右就可頒發證書，若是其他類型證書則是需要通過CA機構進行驗證之後才可頒發。

第三步 發送驗證郵件到管理員郵箱

權威CA機構獲得資料後，將發送一封確認信到管理員郵箱，信中將包含一個 對應的鏈接過去。每一個訂單，都有一個唯一的PIN以做驗證用。

第四步 郵件驗證

點擊確認信中的鏈接，可以訪問到CA機構驗證網站，在驗證網站，可以看到該訂單的申請資料，然後點擊」I Approve」完成郵件驗證。

第五步 頒發證書

在用戶完成郵件驗證之後，CA機構會將證書通過郵件方式發送到申請人自己的郵箱，當用戶收到證書後直接安裝就可以了。若安裝存在問題，我們是提供免費證書安裝服務的。

『叄』 https證書驗證過程是什麼樣的

https證書即SSL證書，其一系列的驗證過程如下：

檢查SSL證書是否被頒發機構吊銷

檢查SSL證書中的證書吊銷列表，如果已經被吊銷，則會顯示警告信息：「此組織的證書已被吊銷。安全證書問題可能顯示試圖欺騙您或截獲您向伺服器發送的數據。建議關閉此網頁，並且不要繼續瀏覽該網站。」

檢查此SSL證書時間是否過期

檢查網站SSL證書的有效期限，如果證書已經過了有效期，則會顯示警告信息：「此網站出具的安全證書已過期或還未生效。安全證書問題可能顯示試圖欺騙您或截獲您向伺服器發送的數據。建議關閉此網頁，並且不要繼續瀏覽該網站。」

檢查網站的域名是否與證書中域名一致

檢查部署此SSL證書的網站的域名是否與證書中的域名一致，如果不一致，則瀏覽器也會顯示警告信息：「此網站出具的安全證書是為其他網站地址頒發的。安全證書問題可能顯示試圖欺騙您或截獲您向伺服器發送的數據。建議關閉此網頁，並且不要繼續瀏覽該網站。」

查詢此網站是否被列入欺詐黑名單

如果發現此網站已經被列入欺詐網站黑名單，則會顯示：「IE已發現一個已報告的仿冒網站。仿冒網站假冒其他網站並試圖欺騙您泄漏個人信息或財務信息。建議關閉此網頁，並且不要繼續瀏覽該網站。」

瀏覽器需經過以上幾個方面的檢查後，才會在頁面顯示安全鎖標志，正常顯示部署了SSL證書的加密頁面。以上是關於ssl證書驗證過程的介紹。

『肆』 https 申請怎麼弄

要想網站實現https加密訪問，必須安裝SSL證書，其申請流程如下：

SSL證書一系列的驗證過程如下：

第一步，生成並提交CSR（證書簽署請求）文件

CSR文件一般都可以通過在線生成（或伺服器上生成），申請人在製作的同時系統會產生兩個秘鑰，公鑰CSR和密鑰KEY。選擇了SSL證書申請之後，提交訂單並將製作生成的CSR文件一起提交到證書所在的CA頒發機構。

第二步，CA機構進行驗證

CA機構對提交的SSL證書申請有兩種驗證方式：

第一種是域名認證。系統自動會發送驗證郵件到域名的管理員郵箱（這個郵箱是通過WHOIS信息查詢到的域名聯系人郵箱）。管理員在收到郵件之後，確認無誤後點擊我確認完成郵件驗證。所有型號的SSL證書都必須進行域名認證。

第二種是企業相關信息認證。對於SSL證書申請的是OV SSL證書或者EV SSL證書的企業來說，除了域名認證，還得進行人工核實企業相關資料和信息，確保企業的真實性。

第三步，CA機構頒發證書

由於SSL證書申請的型號不同，所驗證的材料和方式有些區別，所以頒發時間也是不同的。

如果申請的是DV SSL證書最快10分鍾左右就能頒發。如果申請的是OV SSL證書或者EV SSL證書，一般3-7個工作日就能頒發。

『伍』 HTTP換成HTTPS詳細步驟有嗎

實現http轉換為https首先要購買一張ssl證書，這里建議不要使用免費的ssl證書，免費的ssl證書不會對網站進行數據加密，僅僅是把http換成了https，而且免費的證書不是受信任的CA機構頒發的，不被全球所有的瀏覽器信任，比如谷歌、火狐，如果是免費的ssl證書，用戶訪問時瀏覽器會提示安全風險，影響用戶體驗。購買ssl證書後需要提交CSR文件到CA機構完成驗證審核才能安裝部署。
所謂CSR就是由申請人製作的Certificate Secure Request證書請求文件，是在伺服器上生成的，CSR文件內容包括申請的域名、公司名稱、證書公鑰等信息，你也可以在安信SSL證書上購買ssl證書，一般客服會幫助你完成CSR文件的製作的。
之後將CSR文件提交給CA認證，CA一般有2種認證方式：域名認證和企業文檔認證，如果你購買的是等級較低的證書，只需要域名驗證，如果是等級高的證書需要提供企業的營業執照，審核完成後CA機構會頒發證書，然後將ssl證書部署到伺服器端，就可以實現https加密了。
需要提醒的是，對ssl證書安裝、伺服器配置不熟悉的站長來說，轉換過程不一定是那麼順利，建議聯系SSL證書提供商進行解決。

『陸』 HTTPS證書申請有哪幾個步驟

第一步：將CSR提交到代理商
CSR(Certificate Signing Request)文件必須由用戶自己生成，也可以利用在線CSR生成工具。選擇要申請的產品，提交一個新的訂單，並將製作好的CSR文件提交。
第二步 資料提交到CA
當收到您的訂單和CSR後，如果是域名驗證型證書(DV SSL證書)，在域名驗證之後10分鍾左右就可頒發證書，若是其他類型證書則是需要通過CA機構進行驗證之後才可頒發。
第三步 發送驗證郵件到管理員郵箱
權威CA機構獲得資料後，將發送一封確認信到管理員郵箱，信中將包含一個 對應的鏈接過去。每一個訂單，都有一個唯一的PIN以做驗證用。
第四步 郵件驗證
點擊確認信中的鏈接，可以訪問到CA機構驗證網站，在驗證網站，可以看到該訂單的申請資料，然後點擊」I Approve」完成郵件驗證。
第五步 頒發證書
在用戶完成郵件驗證之後，CA機構會將證書通過郵件方式發送到申請人自己的郵箱，當用戶收到證書後直接安裝就可以了。安信SSL提供免費的安裝服務。

『柒』 https安全證書申請方法，怎麼個申請流程

第一步、提交CSR文件

首先需要生成SSL證書申請文件CSR(Certificate Signing Request)。選擇要申請的SSL證書，提交訂單，並將制生成的CSR文件提一起交到所在的SSL CA頒發機構。

第二步、提交訂單到證書服務機構CA

在收到SSL證書訂單和證書請求CSR文件後，系統初步驗證無誤自動提交訂單到證書服務機構CA。

第三步、發送驗證郵件到管理員郵箱

證書服務機構（主要包括Comodo / RapidSSL / GeoTrust / Symantec / Thawte / VeriSign）在收到證書申請文件CSR 文件系統自動發送驗證郵件到域名管理員郵箱。

第四步、用戶確認驗證郵件

進入郵箱後，點擊郵件中的鏈接訪問證書服務機構驗證網站，查看訂單信息，確認無誤後點擊確認完成郵件驗證。

第五步、證書機構簽發證書

域名型證書DV SSL一般在用戶完成確認驗證郵件後1－24小時簽發證書；企業型證書OV SSL 與 增強型證書EV SSL需要證書服務機構人工驗證，驗證時間比較長，需要7-15個工作日驗證通過後簽發證書；成功簽發的證書通過郵件發送到用戶訂購郵箱，也可登錄用戶中心查詢證書，這樣網站就能夠成功使用SSL證書了。

『捌』 https證書申請需要什麼材料、具體流程是什麼、大概多長時間

1、生成證書請求文件csr（申請沃通ssl，csr文件由系統自動生成）
2、選擇ca機構申請https證書（沃通ca）
3、將csr提交給ca機構認證
4、獲取https證書並安裝

『玖』 申請https證書的流程是什麼

第一步：將CSR提交到代理商

CSR(Certificate Signing Request)文件必須由用戶自己生成，也可以利用在線CSR生成工具內。選擇要申容請的產品，提交一個新的訂單，並將製作好的CSR文件提交。

第二步 資料提交到CA

當收到您的訂單和CSR後，如果是域名驗證型證書(DV SSL證書)，在域名驗證之後10分鍾左右就可頒發證書，若是其他類型證書則是需要通過CA機構進行驗證之後才可頒發。

第三步 發送驗證郵件到管理員郵箱

權威CA機構獲得資料後，將發送一封確認信到管理員郵箱，信中將包含一個 對應的鏈接過去。每一個訂單，都有一個唯一的PIN以做驗證用。

第四步 郵件驗證

點擊確認信中的鏈接，可以訪問到CA機構驗證網站，在驗證網站，可以看到該訂單的申請資料，然後點擊」I Approve」完成郵件驗證。

第五步 頒發證書

在用戶完成郵件驗證之後，CA機構會將證書通過郵件方式發送到申請人自己的郵箱，當用戶收到證書後直接安裝就可以了。若安裝存在問題，我們是提供免費證書安裝服務的。