整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
我們日常上網過程中，經常會遇到打開一個網頁，網頁都還沒有顯示出來，一堆廣告就彈出來的現象。或者網頁剛剛打開，沒幾分鐘 就會彈出來某游戲廣告，注冊領豪華坐騎等等的小廣告。這些廣告不僅僅會讓我們對網站的真實性產生懷疑，另外一方面也會大大影響訪問瀏覽網頁時的觀感。
網頁被劫持強加廣告的亂像在互聯網上很常見，對網站管理員和用戶訪問來說都會造成困擾。這種問題通常是運營商進行http劫持所導致的，要解決運營商劫持的問題，將http協議升級成為https協議是一種非常有效的方式。
如何將http協議升級成https協議
HTTPS的工作原理主要是在HTTP的基礎上加入了SSL/TLS協議，用于對數據傳輸進行加密處理，從而防止數據被第三方竊取和篡改。相較于傳統的HTTP，HTTPS提供了更加可靠的信息安全保護措施。
打開SSL證書服務商，如DigiCert、GlobalSign、GeoTrust。像國產JoySSL證書服務商可以提供免費的SSL證書供個人用戶，企業用戶，政務機構等等的使用和申請。
以國產JoySSL申請SSL證書為例，打開JoySSL官網，用手機或者微信掃碼注冊登錄，填寫注冊碼230921。在證書選擇時選擇需要的SSL證書。
PC打開JoySSL官網，填寫注冊碼230921，即可免費申請SSL證書，解決強制廣告植入問題。
https://www.joyssl.com/certificate/select/free.html?nid=21
在申請證書時，選擇需要的證書類型，如網站只有一個域名就申請單域名證書，如果網站有多個域名，可以申請多域名證書或者通配符證書，等等。
申請證書過程中需要填寫所需要保持的域名，有部分證書還需要填寫單位信息，聯系人，郵箱等等，按步驟申請即可，要注意的是域名等等信息的填寫正確。
證書申請之后對所需要保護的域名進行驗證，簽發，以及后面的部署工作，這個部分因為每個域名的web環境不同，可以按web環境下安裝證書的教程來操作，如果不會操作也可以直接聯系客服處理。
層出不窮的頁面小廣告
在互聯網發展的現在，越來越多的網站出現，比如個人博客、單位官網、政務單位、醫院機構、金融公司等等，網站所需要展示給用戶看的信息需要被保護，傳輸過程中進行加密是非常重要的手段，而廣告的強行植入會直接影響用戶的訪問體驗，部分用戶有可能會誤觸廣告而上當受騙。HTTPS的工作原理加入了SSL/TLS協議，用于對數據傳輸進行加密處理，從而防止數據被第三方竊取和篡改，對網站本身和用戶來說，都起到重要的作用。
見的https網站做的是服務端認證（server authentication），瀏覽器通過證書判斷你所訪問的https://baidu.com是否真的是百度，而不是其他人偽造的網站。同時還對流量加密，防止別人竊聽你的流量。
tls還可以做客戶端認證（client authentication），即服務端判斷客戶端是否為其所信任的客戶端。由此可見，客戶端認證用于那些需要受控訪問服務端。
在數據中心中，有些服務是非常敏感的，那么我們要做到：
所以很明顯，前兩個問題可以通過服務端認證解決，最后一個問題可以通過客戶端認證解決。順便一提，如果要使用客戶端認證就必須使用服務端認證。
先來講講概念然后舉個tomcat的例子講講怎么做。
概念
服務端認證
不論是做Server authentication還是Client authentication都需要證書。證書的來源有兩種：
在一切可能的情況下都應該使用權威CA簽發的證書，為什么這么建議？因為這里牽涉到一個信任問題，瀏覽器、編程語言SDK和某些工具都維護了一個信任CA證書清單，只要是由這些CA簽發的證書那就信任，否則就不信任。而這個鏈條是可以多級的，這里就不展開了。你只需要知道由信任CA簽發的所有證書都是可信的。比如JDK自帶的信任CA證書可以通過下面命令看到：
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts verisignclass2g2ca [jdk], 2016-8-25, trustedCertEntry, 證書指紋 (SHA1): B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D digicertassuredidg3 [jdk], 2016-8-25, trustedCertEntry, 證書指紋 (SHA1): F5:17:A2:4F:9A:48:C6:C9:F8:A2:00:26:9F:DC:0F:48:2C:AB:30:89 verisignuniversalrootca [jdk], 2016-8-25, trustedCertEntry, ...
讓你輸密碼的時候輸入changeit。
如果這個證書不是由信任CA簽發的（比如自己簽發）會發生什么？瀏覽器、編程語言SDK、你所使用的工具會報告以下錯誤：
curl：
curl: (60) SSL certificate problem: self signed certificate in certificate chain
Java：
Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614) ...
瀏覽器：
這個錯誤實際上就是在告訴你這個證書不可信任，可能是一個偽造站點，讓你小心點兒。如果這個證書由權威CA簽發，那么就沒有這個問題了。但是權威CA簽發的證書要求申請人擁有域名，如果你這個服務是內部使用的沒有域名，那就只能自己簽發了。那么如何解決上面的問題呢？你得把自己簽發的證書加入到信任CA證書清單里。
下圖是權威CA簽發證書的示例：
可以看到客戶端有一個truststore，這個就是存放信任CA證書的地方，服務端有一個keystore，存放的自己的證書及對應的私鑰。
下圖是自簽發證書的示例：
在上面可以看到我們自己成為了一個Root CA，把它放到客戶端的truststore里。
客戶端認證
前面講過客戶端認證是服務端來驗證客戶端是否可信的機制，其實做法和服務端認證類似只不過方向相反。客戶端認證大多數情況下只能是自簽發的（因為沒有域名），雖然不是不可以從權威CA簽發但是存在一些問題。下面解釋為什么，假設權威CA是let's encrypt，然后服務端信任它簽發的所有證書。但是let's encrypt是阿貓阿狗都可以申請的，現在有一個黑客申請了這個證書，然后請求你的服務端，服務端就認可了。
上面這個問題可以用這個方法解決：比如你用let's encrypt申請了A證書，黑客用let's encrypt申請了B證書，你的服務端的truststore只信任A證書，那么黑客用B證書訪問你的時候就會被拒絕。但是這就帶來另一個問題，比如你在開發的時候客戶端證書有這么幾套：生產用、調試用、開發用，那么每次客戶端簽發一個證書都要更新到你的服務器的truststore里，這也太麻煩了。
所以結合安全性和便利性，我們把自己變成Root CA，然后服務端信任它，這樣一來服務端就可以在開發的時候把Client Root CA內置進去，大大減輕了維護truststore的工作量，看下圖：
用Tomcat舉個例子
下面舉一個Tomcat做客戶端認證的例子，因為是測試用，所以服務端認證也是用的自簽發證書。
我們用了cfssl這個工具來生成證書。
服務端
先弄一套目錄：
# 放自簽發的服務端CA根證書 server-secrets/ca # 放自簽發的服務端的證書 server-secrets/cert # 放服務端的keystore和truststore server-secrets/jks
生成自簽名CA證書
新建文件：server-secrets/ca/server-root-ca-csr.json
內容如下：
{
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"O": "Company",
"OU": "Datacenter",
"L": "Shanghai",
"ST": "Shanghai",
"C": "CN"
}
],
"CN": "server-root-ca"
}
運行下面命令生成Server ROOT CA證書：
cfssl gencert --initca=true ./server-root-ca-csr.json | cfssljson --bare server-root-ca
會得到下面幾個文件：
server-secrets/ca/ ├── server-root-ca-key.pem ├── server-root-ca.csr └── server-root-ca.pem
用下面命令驗證證書：
openssl x509 -in ./server-root-ca.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 0c:8a:1a:ca:da:fa:4c:17:6c:1f:42:40:4c:f1:90:f4:fd:1d:fe:58 Signature Algorithm: sha256WithRSAEncryption Issuer: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=server-root-ca Validity Not Before: Mar 27 05:14:00 2019 GMT Not After : Mar 25 05:14:00 2024 GMT Subject: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=server-root-ca
可以看到簽發人和被簽發人是同一個。
生成自簽發證書
新建文件 server-secrets/cert/server-gencert.json，內容如下：
{
"signing": {
"default": {
"usages": [
"signing",
"key encipherment",
"server auth"
],
"expiry": "87600h"
}
}
}
可以看到我們會生成用來做server auth的證書。
新建文件 server-secrets/cert/demo-csr.json，內容如下：
{
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"O": "Company",
"OU": "Datacenter",
"L": "Shanghai",
"ST": "Shanghai",
"C": "CN"
}
],
"CN": "server-demo",
"hosts": [
"127.0.0.1",
"localhost"
]
}
看上面的hosts，你可以根據自己的需要填寫域名或IP，這里因為是本地演示所以是127.0.0.1和localhost。
運行下面命令生成證書
cfssl gencert \ --ca ../ca/server-root-ca.pem \ --ca-key ../ca/server-root-ca-key.pem \ --config ./server-gencert.json \ ./demo-csr.json | cfssljson --bare ./demo
得到文件：
server-secrets/cert/ ├── demo-key.pem ├── demo.csr └── demo.pem
驗證結果：
openssl x509 -in ./demo.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 1d:d0:51:97:6c:ce:ea:29:2a:f4:3b:3c:48:a3:69:b0:ef:f3:26:7b Signature Algorithm: sha256WithRSAEncryption Issuer: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=server-root-ca Validity Not Before: Mar 27 05:17:00 2019 GMT Not After : Mar 24 05:17:00 2029 GMT Subject: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=server-demo
可以看到簽發者是server-root-ca，Subject是server-demo。
將證書導入keystore
到 server-secrets/jks，執行下面命令生成pkcs12格式的keystore（JDK識別這個格式）
openssl pkcs12 -export \ -in ../cert/demo.pem \ -inkey ../cert/demo-key.pem \ -out server-demo.keystore \ -name server-demo \ -CAfile ../ca/server-root-ca.pem \ -caname root -chain
過程中會讓你輸入密碼，你就輸入：server-demo-ks。
得到文件：
server-secrets/jks/ └── server-demo.keystore
用JDK提供的keytool看看里面的內容：
keytool -list -keystore server-demo.keystore server-demo, 2019-3-27, PrivateKeyEntry, 證書指紋 (SHA1): B2:E5:46:63:BB:00:E7:82:48:A4:2F:EC:01:41:CE:B4:4B:CE:68:7A
讓你輸入密碼的時候就輸入：server-demo-ks。
客戶端
先弄一套目錄：
# 放自簽發的客戶端CA根證書 client-secrets/ca # 放自簽發的客戶端的證書 client-secrets/cert # 放客戶端的keystore和truststore client-secrets/jks
生成自簽名CA證書
新建文件 client-secrets/ca/client-root-ca-csr.json：
{
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"O": "Company",
"OU": "Datacenter",
"L": "Shanghai",
"ST": "Shanghai",
"C": "CN"
}
],
"CN": "client-root-ca"
}
運行下面命令生成Client ROOT CA證書：
cfssl gencert --initca=true ./client-root-ca-csr.json | cfssljson --bare client-root-ca
會得到下面幾個文件：
client-secrets/ca/ ├── client-root-ca-key.pem ├── client-root-ca.csr └── client-root-ca.pem
用下面命令驗證證書：
openssl x509 -in ./client-root-ca.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 7e:fc:f3:53:07:1a:17:ae:24:34:d5:1d:00:02:d6:e4:24:09:92:12 Signature Algorithm: sha256WithRSAEncryption Issuer: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=client-root-ca Validity Not Before: Mar 27 05:20:00 2019 GMT Not After : Mar 25 05:20:00 2024 GMT Subject: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=client-root-ca
可以看到簽發人和被簽發人是同一個。
生成自簽發證書
新建文件 client-secrets/cert/client-gencert.json，內容如下：
{
"signing": {
"default": {
"usages": [
"signing",
"key encipherment",
"client auth"
],
"expiry": "87600h"
}
}
}
可以看到我們會生成用來做client auth的證書。
新建文件 client-secrets/cert/demo-csr.json，內容如下：
{
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"O": "Company",
"OU": "Datacenter",
"L": "Shanghai",
"ST": "Shanghai",
"C": "CN"
}
],
"CN": "client-demo"
}
這里沒有hosts，這是因為我們不需要用這個證書來做服務端認證。
運行下面命令生成證書
cfssl gencert \ --ca ../ca/client-root-ca.pem \ --ca-key ../ca/client-root-ca-key.pem \ --config ./client-gencert.json \ ./demo-csr.json | cfssljson --bare ./demo
得到文件：
client-secrets/cert/ ├── demo-key.pem ├── demo.csr └── demo.pem
驗證結果：
openssl x509 -in ./demo.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 6e:50:e2:2c:02:bb:ef:fd:03:d9:2c:0a:8f:ba:90:65:fb:c4:b5:75 Signature Algorithm: sha256WithRSAEncryption Issuer: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=client-root-ca Validity Not Before: Mar 27 05:21:00 2019 GMT Not After : Mar 24 05:21:00 2029 GMT Subject: C=CN, ST=Shanghai, L=Shanghai, O=Company, OU=Datacenter, CN=client-demo
可以看到簽發者是client-root-ca，Subject是client-demo。
將證書導入keystore
到 client-secrets/jks，執行下面命令生成pkcs12格式的keystore（JDK識別這個格式）
openssl pkcs12 -export \ -in ../cert/demo.pem \ -inkey ../cert/demo-key.pem \ -out client-demo.keystore \ -name client-demo \ -CAfile ../ca/client-root-ca.pem \ -caname root -chain
過程中會讓你輸入密碼，你就輸入：client-demo-ks。
得到文件：
client-secrets/jks/ └── client-demo.keystore
用JDK提供的keytool看看里面的內容：
keytool -list -keystore client-demo.keystore client-demo, 2019-3-27, PrivateKeyEntry, 證書指紋 (SHA1): 83:AE:0E:5E:0C:CE:86:C9:D1:84:D7:6F:87:F3:76:1F:B4:3E:46:31
讓你輸入密碼的時候就輸入：client-demo-ks。
兩端互信
好了，到此為止server和client的證書都已經生成了，接下來只需要將各自的root-ca添加到彼此都truststore中。
把server-root-ca導入到client的truststore中
cd client-secrets/jks keytool -importcert \ -alias server-root-ca \ -storetype pkcs12 \ -keystore client.truststore \ -storepass client-ts \ -file ../../server-secrets/ca/server-root-ca.pem -noprompt
注意上面的-storepass參數，這個是trustore的密碼：client-ts。
得到文件：
client-secrets/jks/ └── client.truststore
用JDK提供的keytool看看里面的內容：
keytool -list -keystore client.truststore server-root-ca, 2019-3-27, trustedCertEntry, 證書指紋 (SHA1): 75:E3:78:97:85:B2:29:38:25:3C:FD:EC:68:97:9B:78:A0:5F:BB:9D
讓你輸入密碼的時候就輸入：client-ts。
把client-root-ca導入到server的truststore中
cd server-secrets/jks keytool -importcert \ -alias client-root-ca \ -storetype pkcs12 \ -keystore server.truststore \ -storepass server-ts \ -file ../../client-secrets/ca/client-root-ca.pem -noprompt
注意上面的-storepass參數，這個是trustore的密碼：server-ts。
得到文件：
server-secrets/jks/ └── server.truststore
用JDK提供的keytool看看里面的內容：
keytool -list -keystore server.truststore client-root-ca, 2019-3-27, trustedCertEntry, 證書指紋 (SHA1): 1E:95:2C:12:AA:7E:6D:E7:74:F1:83:C2:B8:73:6F:EE:57:FB:CA:46
讓你輸入密碼的時候就輸入：server-ts。
配置Tomcat
好了，我們現在client和server都有了自己證書放在了自己的keystore中，而且把彼此的root-ca證書放到了自己的truststore里。現在我們弄一個tomcat作為server，然后為他配置SSL。
修改tomcat/conf/server.xml，添加如下Connector：
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true"> <SSLHostConfig certificateVerification="required" truststoreFile="/path/to/server-secrets/jks/server.truststore" truststorePassword="server-ts" truststoreType="PKCS12"> <Certificate certificateKeyAlias="server-demo" certificateKeystoreFile="/path/to/server-secrets/demo-jks/server-demo.keystore" certificateKeystoreType="PKCS12" certificateKeystorePassword="server-demo-ks" type="RSA" /> </SSLHostConfig> </Connector>
可以看到我們開啟了客戶端認證certificateVerification="required"，也開啟了服務端認證<Certificate>。記得修改上面的keystore和truststore的路徑。
修改tomcat/conf/web.xml，添加如下元素：
<security-constraint> <web-resource-collection> <web-resource-name>Automatic Forward to HTTPS/SSL</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>
這個作用是當訪問8080端口時，都跳轉到8443端口，強制走HTTPS。
啟動tomcat：
tomcat/bin/catalina.sh run
用curl測試
好了，我們現在用curl來測試訪問一下：
curl https://localhost:8443/ curl: (60) SSL certificate problem: self signed certificate in certificate chain ...
看到curl說服務端用的是一個自簽發的證書，不可信，也就是說服務端認證失敗。添加--insecure試試：
curl --insecure https://localhost:8443/ curl: (35) error:1401E412:SSL routines:CONNECT_CR_FINISHED:sslv3 alert bad certificate
這里就說明客戶端認證失敗。
所以如果要正確訪問得像下面這樣，指定server-root-ca證書，以及客戶端自己簽發的證書及private key：
curl --cacert server-secrets/ca/server-root-ca.pem \ --key client-secrets/cert/demo-key.pem \ --cert client-secrets/cert/demo.pem \ https://localhost:8443/ <!DOCTYPE html> <html lang="en"> ...
Httpclient測試
我們現在用Httpclient來訪問看看。pom.xml中添加依賴：
<dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> <version>4.5.7</version> </dependency>
Java代碼，記得把文件路徑改掉：
import org.apache.http.HttpEntity;
import org.apache.http.HttpException;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.ssl.SSLContexts;
import org.apache.http.util.EntityUtils;
import javax.net.ssl.SSLContext;
import java.io.File;
import java.io.IOException;
public class Client {
public static void main(String[] args) throws Exception {
SSLContext sslcontext=SSLContexts.custom()
.loadTrustMaterial(
new File("/path/to/client-secrets/demo-jks/client.truststore"),
"client-ts".toCharArray()
)
.loadKeyMaterial(
new File("/path/to/client-secrets/demo-jks/client-demo.keystore"),
"client-demo-ks".toCharArray(),
"client-demo-ks".toCharArray())
.build();
SSLConnectionSocketFactory sslsf=new SSLConnectionSocketFactory(
sslcontext,
SSLConnectionSocketFactory.getDefaultHostnameVerifier());
CloseableHttpClient httpclient=HttpClients.custom()
.setSSLSocketFactory(sslsf)
.build();
HttpGet httpGet=new HttpGet("https://localhost:8443");
CloseableHttpResponse response=httpclient.execute(httpGet);
try {
System.out.println(response.getStatusLine());
HttpEntity entity=response.getEntity();
System.out.println(EntityUtils.toString(entity));
} finally {
response.close();
}
}
}
安全性考慮
關于反向代理
因為服務端認證所需要的證書直接配置在Tomcat上的，因此在做反向代理的時候不能使用SSL Termination模式，而是得使用SSL Passthrough模式。
其他語言、SDK、工具
上面講的方法不是只適用于Tomcat和Httpclient的，TLS的服務端認證與客戶端認證應該在絕大部分的語言、SDK、類庫都有支持，請自行參閱文檔實踐。文中的keystore和truststore是Java特有的，不過不必迷惑，因為它們僅僅起到一個存放證書和private key的保險箱，有些語言或工具則是直接使用證書和private key，比如前面提到的curl。
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發： 721575865
群內提供免費的Java架構學習資料（里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
最近寫小程序，但是小程序的接口得通過https的形式訪問，所以用nginx轉發了一下。想到Google搜索引擎會提高https網站的權重，索性把我的網站改造成同時支持http和https了。看效果
http形式訪問
https形式訪問
我是用LET’S ENCRYPT來生成證書的，這個應該是用的最多的一個工具，也很方便。
我直接參考了官方文檔上關于在CentOS 7上用nginx來讓網站支持https的教程
https://certbot.eff.org/lets-encrypt/centosrhel7-nginx
1.下載
sudo yum install certbot python2-certbot-nginx2.執行命令
默認修改/usr/local/nginx/conf目錄下的nginx.conf文件
certbot --nginx -d www.erlie.cc如果不在這個目錄可以用–nginx-server-root這個參數來指定
certbot --nginx --nginx-server-root=/yourpath -d www.erlie.cc 如果要為多個域名生成的話
-d 域名1 -d 域名2或者每次指定一個，執行多次
過程中會有2個選項1和2
如果選 1，則通過 HTTP 和 HTTPS 都可以訪問。
如果選 2，則所有通過 HTTP 來的請求，都會被 301 重定向到 HTTPS
中途中可能會遇到各種環境問題，Google解決即可。
我說一個我遇到的坑，我原來編譯的時候沒有選擇SSL module，所以我得重新編譯一下，編譯完成之后我是用如下命令重啟的
nginx -s reload結果https訪問一直有問題，后來我才意識到。sbin目錄下重新生成的nginx得重啟才能生效。
nginx -s reload只是熱部署配置文件，二進制文件nginx并不生效
此時http://www.erlie.cc和https://www.erlie.cc就都可以訪問了
server {
listen 80;
server_name www.erlie.cc;
#charset koi8-r;
access_log /usr/local/nginx/logs/access.log combined;
location=/ {
root /product/new-blog-fe/dist/view;
index index.html;
}
location ~ .*\.html$ {
root /product/new-blog-fe/dist/view;
index index.html;
}
location / {
proxy_pass http://127.0.0.1:8080/;
}
location ~ .*\.(gif|jpeg|png|bmp|swf|flv|ico)$ {
root /product/new-blog-fe;
if (-f $request_filename) {
expires 1d;
break;
}
}
location ~ .*\.(js|css)?$ {
root /product/new-blog-fe;
if (-f $request_filename) {
expires 1d;
break;
}
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location=/50x.html {
root html;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/www.erlie.cc/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.erlie.cc/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657最后面的5行就是前面的命令自動幫你生成的，非常方便，都不用自己配置。
可以看到我把接口的請求都轉發到本地http://127.0.0.1:8080/，你應該猜到了這是一個Spring Boot項目
為了讓前端在訪客通過http方式訪問的時候調用http接口。通過https訪問的時候調用https接口，我是這樣做的
nb.js
var conf={
serverHot : window.location.origin
};
var _nb={
request: function (param) {
var _this=this;
$.ajax({
type : param.method || 'get',
url : param.url || '',
dataType : param.type || 'json',
data : param.data || '',
xhrFields : {withCredentials: true},
crossDomain: true,
contentType: param.contentType || 'application/x-www-form-urlencoded;charset=UTF-8',
success: function (res) {
typeof param.success==='function' && param.success(res.data, res.msg);
},
error: function (err) {
typeof param.error==='function' && param.error(err.statusText);
}
})
},
// 獲取服務器地址
getServerUrl : function(path) {
return conf.serverHot + path;
}
}
module.exports=_nb;
123456789101112131415161718192021222324252627282930window.location.origin為拿到https://www.erlie.cc類似這樣的請求地址，可以在瀏覽器自己試一下
user-service.js請求用戶相關的接口
var _nb=require('util/nb.js');
var _user={
// 用戶登錄
login : function(userInfo, resolve, reject){
_nb.request({
url : _nb.getServerUrl('/user/login'),
data : userInfo,
method : 'POST',
success : resolve,
error : reject
});
}
}
module.exports=_user;
123456789101112131415userInfo為請求參數
resolve為調用成功后執行的函數
reject為調用失敗后執行的函數
Let’s Encrypt 的證書90天就過期了，所以，你還要設置上自動化的更新腳本，最容易的莫過于使用 crontab 了。使用 crontab -e 命令加入如下的定時作業（每個月都強制更新一下）輸入
0 0 * * * certbot renew鑒于很多人問我要付費專欄pdf版本，因為專欄不能在電腦閱讀，索性直接開源了，希望能幫助到各位小伙伴
免費領取
免費領取
免費領取
重要的事情說三遍。點擊我的頭像私信專欄即可
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
