https证书中的subject alternative name字段作用及如何生成含该字段的证书

背景

最近,某个运维同事找到我,说测试环境的某个域名(他也在负责维护),假设域名为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

参考了:

https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate

和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字段的用法,以及它为什么重要了。

参考文档

https://mp.weixin.qq.com/s/ce-QN78xwRSTN3ZgWIvQAg

https://stackoverflow.com/questions/6194236/openssl-certificate-version-3-with-subject-alternative-name

https://stackoverflow.com/questions/58845805/error-creating-csr-in-openssl-using-subjectaltname-othername

https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate