背景
最近,某个运维同事找到我,说测试环境的某个域名(他也在负责维护),假设域名为test.baidu.com,以前呢,证书都是用的生产的证书,最近不让用了。问为啥呢,说不安全,现在在整改了,因为证书和私钥肯定要一起部署在服务器上,既然测试环境的服务器部署了生产上的证书,那也就是说私钥也部署在测试服务器上,那自然是不安全。咱们小公司嘛,就是这个样子的,管理不是很规范。
那现在也就是说,要给这个test.baidu.com这个域名,弄一个测试环境的证书。然后,他是运维嘛,办公电脑上装软件的限制比较多,就问我,能不能帮忙生成个test.baidu.com的证书给他,就那种自签名的就行了。
问题
我一想,我们之前有个环境测试https,搞过一个自签名证书,直接发给他就行了,然后他就拿去部署到nginx了。
shell
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)。
这个选项比较方便,选项的注释如下:
shell
G:\openssl-test>openssl req -h
-addext val Additional cert extension key=value pair (may be given more than once)
shell
openssl genrsa -out server.key 2048
保留原有的交互式方式,同时又能指定subjectAltName这些扩展字段。
openssl req -new -out server.csr -key server.key -addext "subjectAltName = DNS:test.baidu.com.cn"
生成的csr文件,我们可以查看:
shell
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:
shell
[ 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
命令如下:
shell
openssl req -new -key server.key -out server1.csr -config csr.conf
目前这个调整后的配置,和我在下面这个教程中的差不多:
https://mp.weixin.qq.com/s/RYbdt2NY-kE3YE2THMnx9A
不过这个教程里的配置还要多一点点,且是通过指定环境变量OPENSSL_CONF的方式来指定配置文件:
shell
[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
shell
这里明确说了,会覆盖 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的选项,这里说了,不指定的话,不会添加任何扩展到证书里。
shell
man x509
-extfile filename
file containing certificate extensions to use. If not specified then no extensions are added to the certificate.
这里也说下正确的方法。
方法1
参考了:
和csr一样,生成证书时,也可以指定一个配置文件:
shell
# 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
在下面的命令中,我们同时指定配置文件,且指定要使用的段名:
shell
[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
证书就生成了,我们查看下证书:
shell
openssl x509 -in server.crt -text -noout

我们在linux中看下对应的注释:
shell
man x509

方法2
上面的方法1,是显式指定,也可以不指定具体的段,仅指定配置文件:
https://mp.weixin.qq.com/s/ce-QN78xwRSTN3ZgWIvQAg
创建一个文件:cert.conf
shell
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = test.baidu.com
shell
openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 365 -sha256 -extfile cert.conf
我们查看下,也是ok的:

jdk1.8中如何校验SAN字段
我这里拿deepseek网站来举例吧,我们通过浏览器,能看到它的证书的SAN字段:

可以看到,内容为:
shell
Not Critical
DNS Name: *.deepseek.com
DNS Name: deepseek.com
接下来,看如下的代码:
shell
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字段的用法,以及它为什么重要了。