1. 為什么會出現(xiàn)"No subject alternative names present"錯(cuò)誤？

當(dāng)你用Java程序通過HTTPS訪問某個(gè)網(wǎng)站時(shí)，突然蹦出"java.security.cert.CertificateException: No subject alternative names present"這個(gè)錯(cuò)誤，十有八九是因?yàn)镾SL證書配置出了問題。這個(gè)錯(cuò)誤的核心在于證書缺少主題備用名稱（Subject Alternative Names，簡稱SANs），而現(xiàn)代Java安全機(jī)制強(qiáng)制要求驗(yàn)證這個(gè)字段。

簡單來說，SANs就像是一張身份證上的多個(gè)身份信息。傳統(tǒng)的SSL證書只認(rèn)**Common Name（CN）**字段，就像身份證上只寫了一個(gè)名字。但現(xiàn)實(shí)情況是，一個(gè)網(wǎng)站可能有多個(gè)域名（比如example.com和www.example.com），甚至需要支持IP地址直接訪問。這時(shí)候就需要SANs來記錄所有這些合法的訪問方式。

我在實(shí)際項(xiàng)目中遇到過這樣一個(gè)案例：開發(fā)團(tuán)隊(duì)為內(nèi)部測試環(huán)境配置了HTTPS，用OpenSSL生成了自簽名證書，只填寫了CN字段。結(jié)果用Java程序調(diào)用接口時(shí)，就遇到了這個(gè)經(jīng)典錯(cuò)誤。后來發(fā)現(xiàn)是因?yàn)镴DK 1.8之后加強(qiáng)了對SANs的校驗(yàn)，而他們生成的證書沒有包含這個(gè)擴(kuò)展字段。

2. 深入理解SANs的工作原理

2.1 SANs與CN字段的歷史演變

早期SSL/TLS證書驗(yàn)證主要依賴CN字段，但隨著互聯(lián)網(wǎng)發(fā)展，這種單一標(biāo)識的方式暴露出了明顯缺陷：

• 一個(gè)證書只能對應(yīng)一個(gè)域名
• 不支持通配符以外的多域名配置
• IP地址無法被有效驗(yàn)證

SANs擴(kuò)展就是為了解決這些問題而生的。它可以包含多種類型的標(biāo)識：

• DNS名稱：example.com、*.example.com
• IP地址：192.168.1.1
• 電子郵件地址：user@example.com
• URI：https://example.com

2.2 Java的嚴(yán)格驗(yàn)證機(jī)制

Java安全模型對證書驗(yàn)證特別嚴(yán)格，尤其是JDK 1.8及更高版本。當(dāng)Java程序建立HTTPS連接時(shí)，會執(zhí)行以下驗(yàn)證步驟：

1. 檢查證書是否過期
2. 驗(yàn)證證書鏈?zhǔn)欠窨尚?/li>
3. 核對當(dāng)前訪問的主機(jī)名是否匹配證書中的標(biāo)識
   • 先檢查SANs字段
   • 如果沒有SANs，才回退到CN字段
   • 如果兩者都不匹配，就拋出我們看到的錯(cuò)誤

這種機(jī)制導(dǎo)致很多歷史遺留證書在現(xiàn)代Java環(huán)境下無法正常工作。我見過不少團(tuán)隊(duì)在升級JDK版本后突然出現(xiàn)這個(gè)錯(cuò)誤，就是因?yàn)槔献C書沒有配置SANs擴(kuò)展。

3. 測試環(huán)境下的解決方案

對于開發(fā)和測試環(huán)境，我們可以用OpenSSL快速生成包含SANs的自簽名證書。下面是我在實(shí)際工作中總結(jié)的最佳實(shí)踐：

3.1 準(zhǔn)備SANs配置文件

首先創(chuàng)建一個(gè)san.cnf文件，內(nèi)容如下：

[req]
req_extensions = v3_req
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = *.example.com
IP.1 = 192.168.1.100

這個(gè)配置文件定義了：

• 兩個(gè)DNS記錄：主域名和通配符子域名
• 一個(gè)IP地址訪問方式

3.2 分步生成證書

# 生成私鑰
openssl genpkey -algorithm RSA -out server.key
# 生成證書簽名請求(CSR)
openssl req -new -key server.key -out server.csr \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/CN=example.com" \
  -reqexts v3_req -config san.cnf
# 生成自簽名證書
openssl x509 -req -days 365 -in server.csr \
  -signkey server.key -out server.crt \
  -extfile san.cnf -extensions v3_req

關(guān)鍵參數(shù)說明：

• -subj：設(shè)置證書主體信息，CN必須與主要域名一致
• -reqexts和-extensions：啟用SANs擴(kuò)展配置
• -days：證書有效期，測試環(huán)境可以設(shè)長一些

3.3 快速驗(yàn)證證書

生成證書后，可以用這個(gè)命令檢查SANs是否設(shè)置成功：

openssl x509 -in server.crt -text -noout | grep -A 1 "Subject Alternative Name"

正確輸出應(yīng)該顯示你在配置文件中定義的所有SANs條目。

4. 生產(chǎn)環(huán)境處理方案

生產(chǎn)環(huán)境的證書管理要謹(jǐn)慎得多，這里分享幾種常見場景的解決方案：

4.1 聯(lián)系證書頒發(fā)機(jī)構(gòu)(CA)

正規(guī)CA頒發(fā)的證書通常都包含SANs擴(kuò)展。如果遇到這個(gè)問題：

1. 檢查現(xiàn)有證書是否包含正確的SANs：

   openssl x509 -in production.crt -text -noout | grep -A 1 "Subject Alternative Name"

2. 如果沒有或不全，聯(lián)系CA重新簽發(fā)證書
3. 提供需要添加的所有域名和IP地址

大多數(shù)商業(yè)CA都提供免費(fèi)重新簽發(fā)服務(wù)。去年我們?yōu)橐粋€(gè)電商平臺遷移到新域名時(shí)，就通過DigiCert在2小時(shí)內(nèi)獲得了更新后的多域名證書。

4.2 代碼級解決方案（最后手段）

如果暫時(shí)無法更新證書，可以修改Java代碼繞過驗(yàn)證（僅限緊急情況）：

TrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
        public java.security.cert.X509Certificate[] getAcceptedIssuers() {
            return null;
        }
        public void checkClientTrusted(
            java.security.cert.X509Certificate[] certs, String authType) {
        }
        public void checkServerTrusted(
            java.security.cert.X509Certificate[] certs, String authType) {
        }
    }
};
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

重要警告：這種方法會完全禁用SSL驗(yàn)證，存在嚴(yán)重安全風(fēng)險(xiǎn)。只應(yīng)在測試或內(nèi)部可信網(wǎng)絡(luò)中使用，生產(chǎn)環(huán)境強(qiáng)烈建議使用正規(guī)證書。

5. 常見問題排查技巧

在實(shí)際運(yùn)維中，我總結(jié)了一些排查這類問題的實(shí)用技巧：

5.1 證書鏈完整性檢查

有時(shí)候問題不在終端證書，而在中間證書。用這個(gè)命令檢查完整鏈：

openssl verify -CAfile ca-bundle.crt your-certificate.crt

如果顯示"OK"表示鏈完整，否則需要補(bǔ)充缺失的中間證書。

5.2 不同Java版本的差異

注意JDK版本間的行為差異：

• JDK 7及更早：主要檢查CN字段
• JDK 8：開始強(qiáng)制檢查SANs
• JDK 11+：對SANs的檢查更加嚴(yán)格

可以用以下代碼檢查當(dāng)前JVM使用的安全策略：

System.out.println("Security providers:");
for (Provider p : Security.getProviders()) {
    System.out.println(p.getName());
}

5.3 瀏覽器與Java的不同表現(xiàn)

經(jīng)常有開發(fā)者困惑："為什么瀏覽器訪問正常，Java程序就報(bào)錯(cuò)？"這是因?yàn)椋?/p>

• 現(xiàn)代瀏覽器會回退到CN字段驗(yàn)證
• 瀏覽器會緩存中間證書，而Java可能需要完整鏈
• 瀏覽器有更寬松的證書過期處理機(jī)制

這種差異正是SSL/TLS實(shí)現(xiàn)碎片化的典型表現(xiàn)。

到此這篇關(guān)于Java SSL證書錯(cuò)誤：No subject alternative names present的解決方案的文章就介紹到這了,更多相關(guān)Java SSL證書錯(cuò)誤內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論