『壹』 如何給網站免費添加Https加密
免費添加https加密申請免費的SSL證書就可以了，一般不建議大家使用免費的SSL證書，因為它和付費的SSL證書有很多差別：
1、驗證類型
免費SSL證書只有域名驗證性型（DV SSL證書），而付費SSL證書有域名驗證型（DV SSL證書）、企業驗證型（OV SSL證書）、組織驗證型（EV SSL證書）。
免費SSL證書僅需要域名驗證不需要對企業和組織進行驗證，因此留下了很大的安全漏洞和隱患。第三者只需驗證域名信息就能輕松獲得證書，從而為自己披上看似可信的外衣。此時的https仍可起到加密傳輸的作用，但信息傳輸的目的卻由真實網站的伺服器變成了第三者的「釣魚」伺服器，信息加密也就如同虛設，第三者抓取用戶敏感信息就變得輕而易舉。
2、使用限制
免費SSL證書在使用時還有諸多限制，比如：免費SSL證書只能綁定單個域名、不支持通配符域名、多域名等。此時相關服務也會大打折扣，大多數免費的SSL證書都由用戶自行安裝，無法提供後期服務和技術支持，在遇到SSL證書安裝問題時，也無法得到解決。
而提供付費SSL證書的商家，一般會提供申請購買到安裝的一系列訪問，後續出現問題，還找提供商尋求解決。
3、使用時間
免費SSL證書有效期過短，每三個月或者一個月就要更新一次，到期後還要自己申請，很多用戶很容易就會忘記續期。
而付費SSL證書的使用年限一般是1年，不用時時刻刻擔心證書過期的問題。而且證書服務商會有一個到期提醒，更不用擔心。
4、選擇多樣性
目前提供免費SSL證書的Lets Encrypt、Comodo等，而付費SSL證書選擇性就大得多，Comodo、GeoTrust、Symantec、RapidSSL等知名CA機構。
總的來說，免費的SSL證書，適用於個人博客，作為一個臨時的解決方案。企業或流量較高的個人網站還是選擇付費的SSL證書比較好。
『貳』 https證書不受信任是什麼原因如何解決https證書不受信任
https證書即SSL證書，不受信任的原因如下：
原因一：證書來自不信任的CA機構
CA機構就是證書的頒發機構。如果對SSL證書有所了解，那麼大家應該知道，證書是任何人都可以發布的，我們可以自己給自己的網站頒發證書，我們也可以把我們自己製作的證書給別人安裝。這種證書是完全不需要成本的，只需要你對證書有一定的了解，但是這種證書是默認不受其他客戶端信任的，通常客戶端會提示「該證書來自不信任的CA機構」。目前全球權威CA機構有Symantec、GeoTrust、Comodo以及RapidSSL等多家。
原因二：證書過期
SSL證書都是有有效期的，如果站長購買後部署了證書，然後就忘記了證書這一件事情。等到有一天突然有用戶說，你們的網站怎麼顯示的紅色警告圖標。這時候才開始排查問題，那麼首先應該檢查的就是證書是否過了有效期，如果過了有效期，證書應該及時續費或者使用其他證書，最好是在證書快要過期前的一兩周續費，以免影響網站後續的使用。如果證書被吊銷，也會顯示日期過期，這種要立刻聯系證書提供商，查找吊銷原因，及時解決。
原因三：證書的不完整
在申請證書的時候，經常會由於用戶的疏忽或者是第一次申請，不是很懂，導致沒有完全看懂申請規則，這樣在申請時候就會導致域名匹配不正確，比如填寫CSR的時候定義了anxinssl.com這個頂級域名，但是並沒有定義https://www.anxinssl.com這個二級域名，這個時候就會提示，證書非該域名信任證書。
原因四：戶端不支持SNI協議
一般這種情況發生在Windows XP系統中，安卓4.2以下版本也會發生這種情況，大多數原因是因為這些系統時代太久遠了，目前使用的人數非常之少，也不建議大家使用。這些比較古老的系統中大多是不支持SNI(Server Name Indication，伺服器名字指示)協議的，不過目前主流的操作系統都是支持這個協議的，大家也不用太擔心。
『叄』 怎樣設置打開某網站時只能使用HTTPS
有個前提是，該網站部署了SSL證書，並且開啟了HTTPS協議訪問，你才可以通過HTTPS去訪問。如果你要針對某個網站，比如http://www..com，https和http都可以訪問，你可以通過谷歌瀏覽器設置，強制HTTPS訪問。
『肆』 如何屏蔽https網站 禁止訪問https的方法
一、淘寶一個SSL證書。二、准備好域名、雲伺服器或者支持SSL的主機。三、按照機構商家簽發證書並且完成安裝。四、完成，並且測試網站是否存在HTTP普通協議，如果有修改成HTTPS即可。
『伍』 網站怎麼啟用https訪問
密，因此，所傳送的數據不容易被網路黑客截獲和破解。本文介紹HTTPS的三種實現方法
。
方法一 靜態超鏈接
這是目前網站中使用得較多的方法，也最簡單。在要求使用SSL進行傳輸的Web網頁鏈接
中直接標明使用HTTPS協議，以下是指向需要使用SSL的網頁的超鏈接：
<a href=「https://192.168.100.100/ok/securePage.jsp」>SSL例子</a>
需要說明的是，在網頁里的超鏈接如果使用相對路徑的話，其默認啟用協議與引用該超
鏈接的網頁或資源的傳輸協議相同，例如在某超鏈接「https://192.168.100.100/ok/l
ogin.jps」的網頁中包含如下兩個超鏈接：
<a href=「./bessl/exam.jsp」>SSL鏈接</a>
<a href=「http://192.168.100.100/notssl/index.jsp」>非SSL鏈接
那麼，第一個鏈接使用與「https://192.168.100.100/ok/login.jsp」相同的傳輸協議
HTTPS，第二個鏈接使用本身所標識的協議HTTP。
使用靜態超鏈接的好處是容易實現，不需要額外開發。然而，它卻不容易維護管理; 因
為在一個完全使用HTTP協議訪問的Web應用里，每個資源都存放在該應用特定根目錄下的
各個子目錄里，資源的鏈接路徑都使用相對路徑，這樣做是為了方便應用的遷移並且易
於管理。但假如該應用的某些資源要用到HTTPS協議，引用的鏈接就必須使用完整的路徑
，所以當應用遷移或需要更改URL中所涉及的任何部分如：域名、目錄、文件名等，維護
者都需要對每個超鏈接修改，工作量之大可想而知。再者，如果客戶在瀏覽器地址欄里
手工輸入HTTPS協議的資源，那麼所有敏感機密數據在傳輸中就得不到保護，很容易被黑
客截獲和篡改！
方法二 資源訪問限制
為了保護Web應用中的敏感數據，防止資源的非法訪問和保證傳輸的安全性，Java Serv
let 2.2規范定義了安全約束（Security-Constraint）元件，它用於指定一個或多個We
b資源集的安全約束條件；用戶數據約束（User-Data-Constraint）元件是安全約束元件
的子類，它用於指定在客戶端和容器之間傳輸的數據是如何被保護的。用戶數據約束元
件還包括了傳輸保證（Transport-Guarantee）元件，它規定了客戶機和伺服器之間的通
信必須是以下三種模式之一：None、Integral、Confidential。None表示被指定的Web資
源不需要任何傳輸保證；Integral表示客戶機與伺服器之間傳送的數據在傳送過程中不
會被篡改; Confidential表示數據在傳送過程中被加密。大多數情況下，Integral或Co
nfidential是使用SSL實現。
這里以BEA的WebLogic Server 6.1為例介紹其實現方法，WebLogic是一個性能卓越的J2
EE伺服器，它可以對所管理的Web資源，包括EJB、JSP、Servlet應用程序設置訪問控制
條款。假設某個應用建立在Weblogic Server里的/mywebAPP目錄下，其中一部分Servle
ts、JSPs要求使用SSL傳輸，那麼可將它們都放在/mywebAPP/sslsource/目錄里，然後編
輯/secureAPP/Web-INF/web.xml文件，通過對web.xml的設置可達到對Web用戶實現訪問
控制。
當Web用戶試圖通過HTTP訪問/sslsource目錄下的資源時，Weblogic Server就會查找we
b.xml里的訪問約束定義，返回提示信息：Need SSL connection to access this reso
urce。資源訪問限制與靜態超鏈接結合使用，不僅繼承了靜態超鏈接方法的簡單易用性
，而且有效保護了敏感資源數據。然而，這樣就會存在一個問題： 假如Web客戶使用HT
TP協議訪問需要使用SSL的網路資源時看到彈出的提示信息: Need SSL connection to
access this resource，大部分人可能都不知道應該用HTTPS去訪問該網頁，造成的後果
是用戶會放棄訪問該網頁，這是Web應用服務提供商不願意看到的事情。
方法三 鏈接重定向
綜觀目前商業網站資源數據的交互訪問，要求嚴格加密傳輸的數據只佔其中一小部分，
也就是說在一個具體Web應用中需要使用SSL的服務程序只佔整體的一小部分。那麼，我
們可以從應用開發方面考慮解決方法，對需要使用HTTPS協議的那部分JSPs、Servlets或
EJBs進行處理，使程序本身在接收到訪問請求時首先判斷該請求使用的協議是否符合本
程序的要求，即來訪請求是否使用HTTPS協議，如果不是就將其訪問協議重定向為HTTPS
，這樣就避免了客戶使用HTTP協議訪問要求使用HTTPS協議的Web資源時，看到錯誤提示
信息無所適從的情況，這些處理對Web客戶來說是透明的。
實現思想是：首先創建一個類，該類方法可以實現自動引導Web客戶的訪問請求使用HTT
PS協議，每個要求使用SSL進行傳輸的Servlets或JSPs在程序開始時調用它進行協議重定
向，最後才進行數據應用處理。
J2EE提供了兩種鏈接重定向機制。第一種機制是RequestDispatcher介面里的forward()
方法。使用MVC(Model-View-Controller)機制的Web應用通常都使用這個方法從Servlet
轉移請求到JSP。但這種轉向只能是同種協議間的轉向，並不能重定向到不同的協議。第
二種機制是使用HTTPServletReponse介面里的sendRedirect()方法，它能使用任何協議
重定向到任何URL，例如：
BeSslResponse.sendRedirect(「https://192.168.100.100/order」);
此外，我們還需使用到Java Servlet API中的兩個方法：ServletRequest介面中的getS
cheme()，它用於獲取訪問請求使用的傳輸協議；HTTPUtils類中的getRequestUrl()，它
用於獲取訪問請求的URL，要注意的是該方法在Servlet 2.3中已被移到HTTPServletReq
uest介面。
以下是實現協議重定向的基本步驟：
1. 獲取訪問的請求所使用的協議；
2. 如果請求協議符合被訪問的Servlet所要求的協議，就說明已經使用HTTPS協議了，不
需做任何處理；
3. 如果不符合，使用Servlet所要求的協議(HTTPS)重定向到相同的URL。
例如，某Web用戶使用HTTP協議訪問要求使用HTTPS協議的資源BeSslServlet，敲入「UR
L：http://192.168.100.100/BeSslServlet」，在執行BeSslServlet時首先使用Proces
sSslServlet．processSsl（）重定向到https://192.168.100.100/BeSslServlet，然後
BeSslServlet與客戶瀏覽器之間就通過HTTPS協議進行數據傳輸。
以上介紹的僅是最簡單的例子，是為了對這種重定向的方法有個初步的認識。假如想真
正在Web應用中實現，還必須考慮如下幾個問題：
● 在Web應用中常常會用到GET或Post方法，訪問請求的URL中就會帶上一些查詢字串，
這些字串是使用getRequesUrl()時獲取不到的，而且在重定向之後會丟失，所以必須在
重定向之前將它們加入到新的URL里。我們可以使用request.getQueryString()來獲取G
ET的查詢字串，對於Post的Request參數，可以把它們轉換成查詢串再進行處理。
● 某些Web應用請求中會使用對象作為其屬性，必須在重定向之前將這些屬性保存在該
Session中，以便重定向後使用。
● 大多數瀏覽器會把對同一個主機的不同埠的訪問當作對不同的主機進行訪問，分用
不同的Session，為了使重定向後保留使用原來的Session，必須對應用伺服器的Cookie
域名進行相應的設置。
以上問題均可在程序設計中解決。
通過程序自身實現協議重定向，就可以把要求嚴格保護的那部分資源與其他普通數據從
邏輯上分開處理，使得要求使用SSL的資源和不需要使用SSL的資源各取所需，避免浪費
網站的系統資源。
『陸』 如何選擇SSL證書來實現https訪問網站
1、根據證書的類型
DV SSL證書(域名驗證型)：只驗證域名所有適合個人網站、博客等站點使用;OV SSL證書(企業驗證型)：驗證網站所屬單位身份，適合於中型企業級用戶使用;EV SSL證書 (擴展驗證型)：擴展驗證網站所屬單位身份，適合高度信任的企業級用戶使用。如金融行業的銀行，電子商務平台。
2、支持的域名數量
SSL證書證書根據不同類型其支持功能也不一樣。一般情況，一張SSL證書對應一個域名。只有通配符證書以及多域名證書才支持多個域名。因此用戶擁有多個域名或者通配符域名，可根據SSL證書的支持類型來選擇。
通配符域名證書，可以保護一個域名以及該域名所有的二級子域名，不限制子域名數量，且添加新的子域名無須重新審核和另外付費，節約了大量的時間和金錢成本。
3、網站加密需求
涉及資金交易、機密信息傳輸等對安全性能要求高的網站，請選擇支持強制128/256位加密的SSL證書，規避部分用戶未升級瀏覽器導致加密位數較低而產生的安全風險。頂級EV SSL證書和企業級OV SSL證書都支持強制128/256位加密，建議此類網站盡量採用安全性能更高的強制加密證書。另外其他不涉及交易、機密數據或敏感信息傳輸的網站，也可根據自身需求和風險評估，選擇價格實惠的自適應加密SSL證書。