前言
隨著網(wǎng)絡(luò)技術(shù)的發(fā)展, 越來(lái)越多的公司開(kāi)始使用https作為網(wǎng)絡(luò)請(qǐng)求協(xié)議, 但是身為這個(gè)時(shí)代的開(kāi)發(fā)者, 卻很少有人了解其中的原理, 每次調(diào)接口的時(shí)候都是浪費(fèi)大量的時(shí)間來(lái)對(duì)接, 聯(lián)調(diào), 排查錯(cuò)誤, 經(jīng)常會(huì)說(shuō)的一句, 接口怎么不通, 而這個(gè)地方的資料雖然產(chǎn)量高但每一篇都很重量級(jí), 導(dǎo)致了開(kāi)發(fā)者學(xué)習(xí)困難, 所以這篇文章產(chǎn)生了, 我會(huì)用解決問(wèn)題的方式來(lái)推進(jìn)文章, 由淺入深, 依次講解, 下面就跟著我們的文章一起來(lái)看吧.
一.概念
百度上一大堆, 想看概念的可以先查一下, 這里使用普通話來(lái)敘述.
http:
全名: Hyper Text Transfer Protocol
描述: 常用的網(wǎng)絡(luò)協(xié)議
https:
全名: Hyper Text Transfer Protocol over Secure Socket Layer
描述: 常用的網(wǎng)絡(luò)協(xié)議, 比http更安全
1.https安全在什么地方呢?
下面就要引入一個(gè)概念ssl, 全名(Secure Sockets Layer 安全套接層), 它是一種安全協(xié)議, 協(xié)議原理是在傳輸層對(duì)請(qǐng)求信息進(jìn)行了加密, 這樣別人就不太會(huì)輕易看到你發(fā)送的信息了.
https = http + ssl
2.https通信原理
https
通信其實(shí)就是加密和解密的過(guò)程, 而其中既用到了對(duì)稱加密(AES)
又用到了非對(duì)稱加密(RSA)
, 對(duì)稱加密很簡(jiǎn)單就是有一串秘鑰, 既可以用它加密又可以用它解密, 非對(duì)稱加密是有一對(duì)秘鑰, 稱為公鑰
和私鑰
, 使用公鑰
進(jìn)行加密的必須使用私鑰
進(jìn)行解密, 使用私鑰
加密的也必須使用公鑰
進(jìn)行解密, 兩個(gè)要是可以互換, 但是私鑰要比公鑰長(zhǎng)一些, 所以公鑰適合用于傳輸
https通信流程大概是這樣的:
1.客戶端訪問(wèn)一個(gè)網(wǎng)站后會(huì)獲得服務(wù)器的
CA證書(shū)
, 首先驗(yàn)證證書(shū)的有效性, 如果有效客戶端就會(huì)取出里面的秘鑰 -- 公鑰(非對(duì)稱加密)
2.然后客戶端自己隨機(jī)生成了一個(gè)未加密的對(duì)稱加密密鑰
, 使用公鑰對(duì)未加密的對(duì)稱加密密鑰
進(jìn)行加密生成加密之對(duì)稱加密秘鑰
, 使用未加密的對(duì)稱加密秘鑰
給要發(fā)送給服務(wù)器的數(shù)據(jù)進(jìn)行加密生成加密數(shù)據(jù)
, 然后把加密之對(duì)稱加密秘鑰
和加密數(shù)據(jù)
發(fā)送給服務(wù)器就能與服務(wù)器通信了, 因?yàn)閿?shù)據(jù)和秘鑰都是加密的, 而且加密之對(duì)稱加密秘鑰
只有服務(wù)器有配對(duì)的私鑰才能解密
3.服務(wù)器收到加密之對(duì)稱加密秘鑰
使用跟公鑰配對(duì)的私鑰(本身就存儲(chǔ)在服務(wù)器上)
進(jìn)行解密得到未加密的對(duì)稱加密秘鑰
, 使用未加密的對(duì)稱加密秘鑰
就可以解密客戶端發(fā)來(lái)的數(shù)據(jù)了
4.服務(wù)器收到客戶端數(shù)據(jù)后, 再次發(fā)送的數(shù)據(jù)還是用未加密的對(duì)稱加密秘鑰
進(jìn)行加密后傳給客戶端, 客戶端收到后用未加密的對(duì)稱加密秘鑰
進(jìn)行解密就能得到完整的數(shù)據(jù)了
二.快速開(kāi)始
我會(huì)從前臺(tái)和后臺(tái)兩個(gè)角度依次講解, 先說(shuō)一下iOS
端如何正常訪問(wèn)https
接口, 再來(lái)說(shuō)一下JAVA
后臺(tái)是怎么配置證書(shū)來(lái)實(shí)現(xiàn)https
訪問(wèn)的.
1.iOS配置https
CA證書(shū):
上面已經(jīng)說(shuō)過(guò)了, ssl證書(shū)一共分為兩種, 自建證書(shū)和CA證書(shū), 那么對(duì)于我們來(lái)說(shuō)CA證書(shū)自然是最省事的, 可以用一句話概括, 跟正常網(wǎng)絡(luò)請(qǐng)求沒(méi)有任何區(qū)別.
甚至你連這個(gè)都不用改動(dòng), YES和NO, 均可以訪問(wèn)通過(guò).(親測(cè))
下面上AF代碼 , 正常的不能再正常了 - -
AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
[manager GET:url parameters:nil progress:^(NSProgress * _Nonnull downloadProgress) {
} success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) {
NSLog(@"%@", responseObject);
} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
NSLog(@"%@", error);
}];
所以公司使用CA證書(shū)你就偷著樂(lè)去吧, 對(duì)開(kāi)發(fā)完全沒(méi)影響.
自建證書(shū):
這個(gè)比起CA證書(shū)就要麻煩很多了, 不過(guò)只要學(xué)會(huì)了方法還是很好解決的.
你通常會(huì)遇到的錯(cuò)誤是這個(gè)
錯(cuò)誤1
Task <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1> load failed with error Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://www.objcat.com:8082/hello, NSErrorFailingURLKey=https://www.objcat.com:8082/hello, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1>, NSLocalizedDescription=cancelled} [-999]
2019-01-09 15:37:31.069920+0800 https網(wǎng)絡(luò)測(cè)試[23697:794090] Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://www.objcat.com:8082/hello, NSErrorFailingURLKey=https://www.objcat.com:8082/hello, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1>, NSLocalizedDescription=cancelled}
2019-01-09 15:37:31.075854+0800 https網(wǎng)絡(luò)測(cè)試[23697:794147] Task <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1> finished with error - code: -999
2019-01-09 15:37:31.077351+0800 https網(wǎng)絡(luò)測(cè)試[23697:794148] Task <6A6DB526-EC21-4E85-BACC-1415D23C3057>.<1> HTTP load failed (error code: -999 [1:89])
Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “objcat.com” which could put your confidential information at risk." UserInfo={NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x600001ff0c80>, NSErrorFailingURLKey=https://objcat.com/api/v1/hello, NSErrorFailingURLStringKey=https://objcat.com/api/v1/hello, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “objcat.com” which could put your confidential information at risk.}
還是這個(gè)
錯(cuò)誤2
Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=(
"<cert(0x7f86d2017400) s: Andy i: Andy>"
), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://www.objcat.com:8082/hello, NSErrorFailingURLStringKey=https://www.objcat.com:8082/hello, NSUnderlyingError=0x600001f21500 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x60000230f2a0>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9802, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, kCFStreamPropertySSLPeerCertificates=(
"<cert(0x7f86d2017400) s: Andy i: Andy>"
)}}, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <F8DB0C28-4CD3-417B-B89B-B0DCCABB6EA6>.<1>"
), _kCFStreamErrorCodeKey=-9802, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <F8DB0C28-4CD3-417B-B89B-B0DCCABB6EA6>.<1>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x60000230f2a0>, NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made.}
或是這個(gè)
錯(cuò)誤3
*** Terminating app due to uncaught exception 'Invalid Security Policy', reason: 'A security policy configured with `AFSSLPinningModeCertificate` can only be applied on a manager with a secure base URL (i.e. https)'
*** First throw call stack:
(
0 CoreFoundation 0x000000010b27029b __exceptionPreprocess + 331
1 libobjc.A.dylib 0x000000010a80c735 objc_exception_throw + 48
2 httpsáΩ?áaúêμ???? 0x0000000109426325 -[AFHTTPSessionManager setSecurityPolicy:] + 613
3 httpsáΩ?áaúêμ???? 0x000000010942276c -[ViewController viewDidLoad] + 172
4 UIKitCore 0x000000010f379781 -[UIViewController loadViewIfRequired] + 1186
5 UIKitCore 0x000000010f379be0 -[UIViewContro
先把下巴合上, 口水擦一擦, 我們下面就來(lái)說(shuō)一下這幾個(gè)錯(cuò)誤都是什么, 該怎么解決.
錯(cuò)誤1 解決方案:
這里提供一個(gè)最好的解法, 也是最簡(jiǎn)單的, 可以用一個(gè)成語(yǔ)來(lái)形容 - 敞門(mén)入場(chǎng), 我什么都不驗(yàn)證, 只想拿到我的數(shù)據(jù), 其他跟我沒(méi)關(guān)系.
首先設(shè)置下面兩項(xiàng)
AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
// 是否允許無(wú)效證書(shū), 默認(rèn)為NO
manager.securityPolicy.allowInvalidCertificates = YES;
// 是否校驗(yàn)域名, 默認(rèn)為YES
manager.securityPolicy.validatesDomainName = NO;
然后這個(gè)地方設(shè)置為YES, Allow Arbitrary Loads
允許任意加載
上述設(shè)置任何網(wǎng)絡(luò)都可以保證通暢訪問(wèn), 如果是來(lái)找答案的, 恭喜你問(wèn)題已經(jīng)解決了.
下面內(nèi)容有可能引起不適 慎讀:
錯(cuò)誤2 解決方案
你在尋找答案的時(shí)候有可能看到另外一種解法, 就是在AF中配置證書(shū)來(lái)保持訪問(wèn)正常, 說(shuō)實(shí)話這種方法是完全不推薦的, 在強(qiáng)調(diào)一遍, 讓公司去買(mǎi)CA證書(shū).
你可能對(duì)下面的代碼很熟悉, 摘自互聯(lián)網(wǎng)
- (AFSecurityPolicy *)customSecurityPolicy {
// 先導(dǎo)入證書(shū) 證書(shū)由服務(wù)端生成酥宴,具體由服務(wù)端人員操作
NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"keystore" ofType:@"cer"];//證書(shū)的路徑 xx.cer
NSData *cerData = [NSData dataWithContentsOfFile:cerPath];
// AFSSLPinningModeCertificate 使用證書(shū)驗(yàn)證模式
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
// allowInvalidCertificates 是否允許無(wú)效證書(shū)(也就是自建的證書(shū))病瞳,默認(rèn)為NO
// 如果是需要驗(yàn)證自建證書(shū),需要設(shè)置為YES
securityPolicy.allowInvalidCertificates = YES;
//validatesDomainName 是否需要驗(yàn)證域名膜眠,默認(rèn)為YES;
//假如證書(shū)的域名與你請(qǐng)求的域名不一致拗踢,需把該項(xiàng)設(shè)置為NO脚牍;如設(shè)成NO的話,即服務(wù)器使用其他可信任機(jī)構(gòu)頒發(fā)的證書(shū)巢墅,也可以建立連接诸狭,這個(gè)非常危險(xiǎn),建議打開(kāi)砂缩。
//置為NO作谚,主要用于這種情況:客戶端請(qǐng)求的是子域名,而證書(shū)上的是另外一個(gè)域名庵芭。因?yàn)镾SL證書(shū)上的域名是獨(dú)立的妹懒,假如證書(shū)上注冊(cè)的域名是www.google.com,那么mail.google.com是無(wú)法驗(yàn)證通過(guò)的双吆;當(dāng)然眨唬,有錢(qián)可以注冊(cè)通配符的域名*.google.com会前,但這個(gè)還是比較貴的。
//如置為NO匾竿,建議自己添加對(duì)應(yīng)域名的校驗(yàn)邏輯瓦宜。
securityPolicy.validatesDomainName = NO;
securityPolicy.pinnedCertificates = [[NSSet alloc] initWithObjects:cerData, nil];
return securityPolicy;
}
路人甲: 對(duì)對(duì)對(duì), 就是這垃圾東西, 我調(diào)了好幾天.
路人乙: 麻蛋的, 我寫(xiě)的都對(duì), 咋訪問(wèn)不通呢, 是不是后臺(tái)證書(shū)給錯(cuò)了.
解決方法也簡(jiǎn)單
1.讓后臺(tái)提供有效的ssl證書(shū), 親測(cè)p12
導(dǎo)出cer
是完全可以使用的
2.檢查你的代碼有沒(méi)有開(kāi)啟 Allow Arbitrary Loads = YES
3.幫助后臺(tái)對(duì)接調(diào)試
然后還有一點(diǎn)就是這個(gè)域名AF
是驗(yàn)證不了的, 所以要設(shè)置為NO, 我猜測(cè)只有CA證書(shū)才能使用AF
中的驗(yàn)證域名
那么有人會(huì)問(wèn)了, 既然你設(shè)置了都不驗(yàn)證(有效性和域名)那還要證書(shū)有個(gè)屁用
, 問(wèn)得好, 我們?cè)趺醋C明證書(shū)是有效的呢, 可以用一個(gè)任意證書(shū)放上去, 驗(yàn)證絕對(duì)是不通過(guò)的, 唯有服務(wù)器端的p12
導(dǎo)出的cer
可以使用, 所以可以證明證書(shū)有效
錯(cuò)誤2就會(huì)在沒(méi)有開(kāi)啟Allow Arbitrary Loads
的時(shí)候出現(xiàn), 因?yàn)樽越ㄗC書(shū)并非正規(guī)的ssl請(qǐng)求, 所以需要開(kāi)啟允許所有訪問(wèn).
然而在你做完這些之后會(huì)遇到錯(cuò)誤3
A security policy configured with `AFSSLPinningModeCertificate` can only be applied on a manager with a secure base URL (i.e. https)'
意思是使用AFSSLPinningModeCertificate
模式必須配置一個(gè)baseURL, 這個(gè)可以是你的域名或者ip, 目前還不知道有什么用, 隨便配置一個(gè)即可.
AFHTTPSessionManager *manager = [[AFHTTPSessionManager manager] initWithBaseURL:[NSURL URLWithString:@"https://www.baidu.com"]];
之后如果沒(méi)什么失誤的話, 就可以訪問(wèn)接口了...
到這里告一段落.
2.Java配置https
CA證書(shū):
首先來(lái)介紹一下CA證書(shū):
一共分為三種
DV SSL
DV SSL證書(shū)是只驗(yàn)證網(wǎng)站域名所有權(quán)的簡(jiǎn)易型SSL證書(shū),可10分鐘快速頒發(fā)岭妖,能起到加密傳輸?shù)淖饔昧俦樱珶o(wú)法向用戶證明網(wǎng)站的真實(shí)身份。
目前市面上的免費(fèi)證書(shū)都是這個(gè)類型的, 只是提供了對(duì)數(shù)據(jù)的加密, 但是對(duì)提供證書(shū)的個(gè)人和機(jī)構(gòu)的身份不做驗(yàn)證昵慌。
例如我自己的證書(shū):
OV SSL
OV SSL, 提供加密功能, 對(duì)申請(qǐng)者做嚴(yán)格的身份審核驗(yàn)證和DV SSL的區(qū)別在于, OV SSL 提供了對(duì)個(gè)人或者機(jī)構(gòu)的審核, 能確認(rèn)對(duì)方的身份, 安全性更高.
所以這部分的證書(shū)申請(qǐng)是收費(fèi)的~
例如百度的證書(shū):
EV SSL
EV最安全, 最嚴(yán)格, 超安EV SSL證書(shū)遵循全球統(tǒng)一的嚴(yán)格身份驗(yàn)證標(biāo)準(zhǔn)假夺,是目前業(yè)界安全級(jí)別最高的頂級(jí)SSL證書(shū), 驗(yàn)證過(guò)身份的公司名稱可以直接顯示在瀏覽器上, 是不是很高大上.
例如證書(shū)頒發(fā)機(jī)構(gòu)的官網(wǎng):
好了下面我們就來(lái)申請(qǐng)一個(gè)免費(fèi)的證書(shū)吧!
首先去阿里云或別的機(jī)構(gòu)申請(qǐng)CA證書(shū), 這里舉例申請(qǐng)一個(gè)免費(fèi)的.
阿里云控制臺(tái) -> 產(chǎn)品與服務(wù) -> 搜索ssl
可以看到證書(shū)很貴, 這里面有一個(gè)免費(fèi)的, 但是點(diǎn)出來(lái)需要點(diǎn)技巧
之后選擇支付就可以了, 支付完成會(huì)發(fā)現(xiàn)多了個(gè)證書(shū)
填寫(xiě)基本信息
然后點(diǎn)驗(yàn)證就可以了, 需要等待一些時(shí)間
------ 一段時(shí)間后 --------
我們可以看到證書(shū)審核好了, 我們就可以直接配置了, 首先把證書(shū)下載下來(lái), 密碼在同目錄的文本文件里, 然后開(kāi)始配置, 這里以springcloud
為例
下載后的證書(shū)是pfx
格式的, 我們先把它導(dǎo)入鑰匙串, 然后導(dǎo)出為p12
文件
然后把證書(shū)放到resources
目錄下, 我改了個(gè)名請(qǐng)忽略 - -
server:
#服務(wù)端口號(hào)
port: 8082
ssl:
key-store: classpath:haha.p12
key-store-password: 123456
key-store-type: PKCS12
之后配置這些即可, 項(xiàng)目會(huì)自動(dòng)開(kāi)啟https
.
之后訪問(wèn)接口試試
我們可以看到證書(shū)是有效的, 這個(gè)服務(wù)器是配置在我本地的, 我們用ip來(lái)訪問(wèn)一下.
我們會(huì)發(fā)現(xiàn), 同樣的接口, 把域名換成ip就不可以訪問(wèn)了, 這也驗(yàn)證了我們DV證書(shū)是校驗(yàn)域名的這個(gè)原理.
我們可以直接在證書(shū)上查看我們信任的域名
自建證書(shū):
自建證書(shū)配置也十分簡(jiǎn)單, 首先用java自帶的keytool來(lái)生成一個(gè)自建證書(shū)
keytool -genkey -alias tomcat -dname "CN=objcat,OU=objcat,O=objcat,L=PuDongXinQu,ST=ShangHai,C=CN" -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650
-genkey
: 制作證書(shū)固有命令
-alias
: 別名
-dname
: 填寫(xiě)證書(shū)基本信息
CN(Common Name 名字與姓氏)
OU(Organization Unit 組織單位名稱)
O(Organization 組織名稱)
L(Locality 城市或區(qū)域名稱)
ST(State 省/市/自治區(qū)名稱)
-storetype
: 證書(shū)保存類型
-keyalg
: 加密方式
-keysize
: 秘鑰長(zhǎng)度
-keystore
: 證書(shū)導(dǎo)出時(shí)的名稱
-validity
: 證書(shū)有效期
然后輸入證書(shū)密碼就可以完成創(chuàng)建了!
雙擊證書(shū), 輸入密碼就能導(dǎo)入鑰匙串了, 我們來(lái)看看
這個(gè)證書(shū)的使用方法和CA證書(shū)一樣
1.放在resources
目錄下
2.填寫(xiě)配置文件 - 參考CA證書(shū)配置
啟動(dòng)服務(wù)!
訪問(wèn)接口
https://localhost:8082/hello
之后點(diǎn)擊繼續(xù)前往
這樣雖然可以訪問(wèn), 但是我們可以看到上面寫(xiě)的三個(gè)紅色的大字, 不安全, 所以我們需要解決一下這個(gè)問(wèn)題, 就是信任證書(shū)!
我們發(fā)現(xiàn)信任證書(shū)之后safari
是可以訪問(wèn)通的, 但是chrome
還是會(huì)報(bào)錯(cuò)不安全
Certificate - Subject Alternative Name missing
The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address.
Certificate - missing
This site is missing a valid, trusted certificate (net::ERR_CERT_COMMON_NAME_INVALID).
然后我們就開(kāi)始著手解決這兩個(gè)問(wèn)題
根據(jù)錯(cuò)誤提示, 是因?yàn)槲业淖C書(shū)沒(méi)有做域名認(rèn)證造成的, 所以我們?cè)谏勺C書(shū)的時(shí)候給它添加一個(gè)域名
加上下面這句即可
-ext san=dns:www.objcat.com
注意這里配置的域名需要和證書(shū)一模一樣才行 本人親自測(cè)試
如果host是127.0.0.1 www.objcat.com
那么上面的證書(shū)是可以使用的
但如果host是127.0.0.1 objcat.com
上面的證書(shū)會(huì)報(bào)出不安全
有人說(shuō)這玩意有啥用啊, 隨便配配就行了啊, 兄弟這關(guān)乎你的訪問(wèn)地址啊
https://www.objcat.com/api/v1/hello
https://objcat.com/api/v1/hello
這兩個(gè)地址完全不一樣好么
如果是想要下面那個(gè)樣子, 你必須把證書(shū)創(chuàng)建為, 下面的樣子才可以
-ext san=dns:objcat.com
創(chuàng)建為這個(gè)樣子后, 經(jīng)過(guò)我的測(cè)試www.objcat.com
和objcat.com
都可以使用, 如果使用前者域名谷歌瀏覽器會(huì)自動(dòng)跳轉(zhuǎn)到后者上面去, 應(yīng)該是對(duì)有無(wú)www
進(jìn)行了處理, 如果www
所在的地址不安全就嘗試去掉www
綜上所述 還是創(chuàng)建-ext san=dns:objcat.com
不帶www
的比較好, 因?yàn)榭梢赃m配兩種情況
完整命令
keytool -genkey -alias tomcat -dname "CN=objcat,OU=objcat,O=objcat,L=PuDongXinQu,ST=ShangHai,C=CN" -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650 -ext san=dns:www.objcat.com
我們?cè)俅紊勺C書(shū), 然后重新配置
之后我們來(lái)修改 www.objcat.com 映射到本機(jī)域名
127.0.0.1 www.objcat.com
然后重啟服務(wù)器
這次試用域名訪問(wèn)接口試試
我們發(fā)現(xiàn)問(wèn)題解決了!