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

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

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

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

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

2.1 SANs與CN字段的歷史演變

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

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

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

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

2.2 Java的嚴格驗證機制

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

1. 檢查證書是否過期
2. 驗證證書鏈是否可信
3. 核對當(dāng)前訪問的主機名是否匹配證書中的標識
   • 先檢查SANs字段
   • 如果沒有SANs，才回退到CN字段
   • 如果兩者都不匹配，就拋出我們看到的錯誤

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

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

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

3.1 準備SANs配置文件

首先創(chuàng)建一個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

這個配置文件定義了：

• 兩個DNS記錄：主域名和通配符子域名
• 一個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擴展配置
• -days：證書有效期，測試環(huán)境可以設(shè)長一些

3.3 快速驗證證書

生成證書后，可以用這個命令檢查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)境的證書管理要謹慎得多，這里分享幾種常見場景的解決方案：

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

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

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ā)服務(wù)。去年我們?yōu)橐粋€電商平臺遷移到新域名時，就通過DigiCert在2小時內(nèi)獲得了更新后的多域名證書。

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

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

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驗證，存在嚴重安全風(fēng)險。只應(yīng)在測試或內(nèi)部可信網(wǎng)絡(luò)中使用，生產(chǎn)環(huán)境強烈建議使用正規(guī)證書。

5. 常見問題排查技巧

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

5.1 證書鏈完整性檢查

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

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

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

5.2 不同Java版本的差異

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

• JDK 7及更早：主要檢查CN字段
• JDK 8：開始強制檢查SANs
• JDK 11+：對SANs的檢查更加嚴格

可以用以下代碼檢查當(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程序就報錯？"這是因為：

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

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

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

最新評論