https證書中的subject alternative name字段作用及如何生成含該字段的證書
背景
最近，某個運維同事找到我，說測試環境的某個域名（他也在負責維護），假設域名為test.baidu.com，以前呢，證書都是用的生產的證書，最近不讓用了。問為啥呢，說不安全，現在在整改了，因為證書和私鑰肯定要一起部署在服務器上，既然測試環境的服務器部署了生產上的證書，那也就是說私鑰也部署在測試服務器上，那自然是不安全。咱們小公司嘛，就是這個樣子的，管理不是很規范。
那現在也就是說，要給這個test.baidu.com這個域名，弄一個測試環境的證書。然后，他是運維嘛，辦公電腦上裝軟件的限制比較多，就問我，能不能幫忙生成個test.baidu.com的證書給他，就那種自簽名的就行了。
問題
我一想，我們之前有個環境測試https，搞過一個自簽名證書，直接發給他就行了，然后他就拿去部署到nginx了。
ssl on;
ssl_certificate comkey.crt;
ssl_certificate_key comkey.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1.2;
結果，過了兩天，他說部署上去后，有個客戶端調用的時候報錯，說證書里有個字段的值沒對。
我給他的證書里，如上圖所示，subject alternative name的內容為：DNS NAME = ma-dev.example.com.cn，而他拿去部署的網站的域名為test.example.com.cn，導致客戶端校驗出錯了，說能不能重新生成下證書給他。
我本來吧，不想弄的，因為我也忘了之前這個證書，怎么會包含這個字段，我也不知道這個字段啥意思。
到后面，還是接了這個事。
嘗試
網上找了個教程：https://cloud.tencent.com/document/product/1552/111585
可惜，生成出來的證書，根本就沒有那個certifacate subject alternative name字段。
他這個生成證書，其實分了三個核心步驟。證書呢，里面一般是包含了公鑰，這個是公開的，瀏覽器拿到證書后，會檢查證書，有一堆規則，比如：驗證證書是由合法的root CA簽發的，沒過期，沒吊銷等，如果都沒問題，就認為證書有效，就會取出證書中包含的各個信息，如公鑰信息。
這個公鑰和服務端私密保存的私鑰（也就是key文件，一般會配置到nginx里），是一一對應的，一般私鑰發生了泄露，這個證書就算是廢了。
所以，回到我們的證書生成環節，也是我們先生成一個私密的key，如上面的openssl genrsa -out server.key 2048這步。
然后呢，用這個key，去生成一個證書簽名請求文件（CSR）。
CSR（Cerificate Signing Request），即證書請求文件，是證書申請者在申請數字證書時，生成私鑰的同時生成證書請求文件。證書申請者把CSR文件提交給證書頒發機構后，證書頒發機構使用其根證書私鑰簽名就生成了證書公鑰文件。
這個CSR里，就要包含我們希望放進證書的各種內容，比如我們本文提到的certifacate subject alternative name這些字段等。CSR準備好了后，提交給各個CA機構，然后CA機構理論上來說，會核查你、你的網站等各種身份信息，核查無誤后，就會用它這家CA的私鑰，對你的CSR進行簽名，然后就生成了一個它這家CA認可的證書了。
后續，你就拿著這個證書，傳輸給用戶的瀏覽器，用戶瀏覽器中，有這家CA的公鑰，自然就能發現你這個證書確實是這家CA的私鑰簽發的，就認可你的證書，后續就能正常通信。
回到我們的問題，首先，我們就必須要保證CSR文件中，包含我們的certifacate subject alternative name字段才行。
生成csr
由于這會在家里，連不上公司vpn了（正好到期了），也沒法演示之前的各種錯誤了。所以就直接記錄一下各種正確的方法。
方法1: addext選項
這個選項是openssl的1.1.1版本才有的。查看版本：openssl version。一般來說，linux服務器的openssl版本升級還是非常慎重的，如果發現版本不支持，那么，有個好辦法，直接在windows上安裝高版本的openssl來生成csr也是一樣的: http://slproweb.com/products/Win32OpenSSL.html 這里可以下載，如（Win64 OpenSSL v3.4.1）。
這個選項比較方便，選項的注釋如下：
G:\openssl-test>openssl req -h
-addext val Additional cert extension key=value pair (may be given more than once)
openssl genrsa -out server.key 2048
保留原有的交互式方式，同時又能指定subjectAltName這些擴展字段。
openssl req -new -out server.csr -key server.key -addext "subjectAltName = DNS:test.baidu.com.cn"
生成的csr文件，我們可以查看：
openssl req -in server.csr -noout -text
網上也可以解碼查看一個csr文件的內容：
https://www.sslshopper.com/csr-decoder.html
方法2: 配置文件
這個方法，我試了下，我的老版本OpenSSL 1.0.2k-fips也是支持的。
本來參考了：https://support.huawei.com/enterprise/zh/doc/EDOC1100296985?section=j025
結果發現行不通。
后面自己調整成全從配置文件中讀了：
csr.conf：
[ req ]
default_bits = 2048
default_md = sha256
prompt = no
distinguished_name = req_distinguished_name
req_extensions = SAN
[ req_distinguished_name ]
C = CN
ST = Sichuan
L = Chengdu
O = BAIDU
OU = IT
CN = test.baidu.com
[ SAN ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = test.baidu.com
IP.1 = 192.168.1.1
命令如下：
openssl req -new -key server.key -out server1.csr -config csr.conf
目前這個調整后的配置，和我在下面這個教程中的差不多：
https://mp.weixin.qq.com/s/RYbdt2NY-kE3YE2THMnx9A
不過這個教程里的配置還要多一點點，且是通過指定環境變量OPENSSL_CONF的方式來指定配置文件：
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = PH
ST = Manila
L = Quezon
O = HCL
CN = test.baidu.com
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = test.baidu.com
這里明確說了，會覆蓋 OPENSSL_CONF 環境變量中的配置。
-config filename
this allows an alternative configuration file to be specified, this overrides the compile time filename or any specified in the OPENSSL_CONF environment variable.
生成自簽名證書
如果大家是生成csr，提交給CA去生成證書，就不涉及這部分。這部分主要是生成自簽名證書的時候遇到的問題。
我之前的時候，遇到的最大問題其實就是生成證書，明明看到csr里面都是有我們需要的選項的，但是，證書里就沒了。其實就是因為，沒指定一個叫extfile的選項，這里說了，不指定的話，不會添加任何擴展到證書里。
man x509
-extfile filename
file containing certificate extensions to use. If not specified then no extensions are added to the certificate.
這里也說下正確的方法。
方法1
參考了：
和csr一樣，生成證書時，也可以指定一個配置文件：
# ssl-extensions-x509.cnf
[v3_ca]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = IP:127.0.0.1, IP:192.168.73.120, IP:192.168.73.121
可以看到，文件里包含了一個段，叫：v3_ca
在下面的命令中，我們同時指定配置文件，且指定要使用的段名：
[root@VM-0-6-centos ssltest]# openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 3650 -extensions v3_ca -extfile ./ssl-extensions-x509.cnf
Signature ok
subject=/C=CN/ST=Sichuan/L=Chengdu/O=BAIDU/OU=IT/CN=test.baidu.com
Getting Private key
證書就生成了，我們查看下證書：
openssl x509 -in server.crt -text -noout
我們在linux中看下對應的注釋：
man x509
方法2
上面的方法1，是顯式指定，也可以不指定具體的段，僅指定配置文件：
https://mp.weixin.qq.com/s/ce-QN78xwRSTN3ZgWIvQAg
創建一個文件：cert.conf
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = test.baidu.com
openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 365 -sha256 -extfile cert.conf
我們查看下，也是ok的：
jdk1.8中如何校驗SAN字段
我這里拿deepseek網站來舉例吧，我們通過瀏覽器，能看到它的證書的SAN字段：
可以看到，內容為:
Not Critical
DNS Name: *.deepseek.com
DNS Name: deepseek.com
接下來，看如下的代碼：
public static void main(String[] args) throws IOException {
URL url = new URL("https://www.deepseek.com/");
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setConnectTimeout(10000);
connection.setReadTimeout(3000);
int responseCode = connection.getResponseCode();
System.out.println(responseCode);
}
我們平時可能習慣了忽略證書校驗，如：
今天我們就簡單看看，不忽略的話，是在什么地方校驗的。
在收到服務端返回的證書的消息時，會進入以下代碼：
然后使用默認的trustManager（sun.security.ssl.X509TrustManagerImpl）來校驗服務端證書：
接著進入如下方法，校驗server和校驗client的方法一樣，只是最后一個參數不同，false就是校驗服務端：
然后如下代碼，就要開始校驗：我們請求時的域名為www.deepseek.com，那么證書到底是不是匹配呢，是不是www.deepseek.com的證書呢？
我們一路深入到如下方法，自始至終，參數就兩個，一個是請求的域名（其實是取了客戶端握手消息時攜帶的SNI字段，正好就是我們請求的域名，所以，就算我們使用https加密，網管也是知道我們在上什么網站的），一個是返回的證書：
接下來，從證書中獲取了SAN字段，這是個集合：
最后就是遍歷這個集合，看看是否匹配我們請求的域名，最終呢，www.deepseek.com就匹配上了SAN中的*.deepseek.com這條，所以，這個校驗就算是ok了。
我們也就大概知道了SAN字段的用法，以及它為什么重要了。
浙公網安備 33010602011771號