最近，某个运维同事找到我，说测试环境的某个域名（他也在负责维护），假设域名为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字段才行。
由于这会在家里，连不上公司vpn了（正好到期了），也没法演示之前的各种错误了。所以就直接记录一下各种正确的方法。
这个选项是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
这个方法，我试了下，我的老版本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.
这里也说下正确的方法。
参考了：
和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
上面的方法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的：
我这里拿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字段的用法，以及它为什么重要了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。