本地测试使用自签名证书以开启网站https（例子说明：Nginx

最新推荐文章于 2024-08-09 14:14:23 发布

2401_84138927

最新推荐文章于 2024-08-09 14:14:23 发布

阅读量967

点赞数 12

分类专栏： 2024年程序员学习文章标签： https nginx 网络

本文链接：https://blog.csdn.net/2401_84138927/article/details/137545314

版权

2024年程序员学习专栏收录该内容

126 篇文章 1 订阅

订阅专栏

-algorithm RSA：此选项指定要使用的密钥算法。在本例中，使用的是 RSA。

-out ca.pem：这告诉 OpenSSL 将生成的密钥写入名为 “ca.pem” 的文件中。

-pkeyopt rsa_keygen_bits:2048：这设置 RSA 密钥的大小为 2048 位。RSA 密钥的位数越大，安全性就越高，但生成和使用密钥的成本也越高。

这将生成一个 RSA 私钥并将其保存到名为 key.pem 的文件中

2.生成根证书签名请求（CSR）

openssl-req文档:https://www.openssl.org/docs/man3.0/man1/openssl-req.html

纯命令行的形式：

openssl req -new -key ca.pem -out ca.csr -subj “/OU=Self Sign CA/O=Self Sign/CN=Self Sign” -addext “keyUsage=critical,keyCertSign,cRLSign” -addext “basicConstraints=critical,CA:TRUE”

req：该选项指定我们要使用“req”子命令来生成CSR。

-new：该选项告诉OpenSSL创建一个新的CSR。

-key ca.pem：该选项指定在创建CSR时要使用的私钥文件的路径。

-out ca.csr：该选项指定要为创建的CSR使用的文件名。

-subj “/OU=Self Sign CA/O=Self Sign/CN=Self Sign”：该选项指定CSR的主题。在此例中，主题设置为通用名称“Self Sign”，组织单位“Self Sign CA”和组织“Self Sign”。

-addext “keyUsage=critical,keyCertSign,cRLSign”：该选项向CSR添加密钥用途扩展。密钥用途扩展指定证书中的公钥可以如何使用。

-addext “basicConstraints=critical,CA:TRUE”：该选项向CSR添加基本约束扩展。基本约束扩展指定证书是否可以用作CA（证书颁发机构）。在此例中，基本约束扩展指示证书可以用作CA。

使用配置文件的方式:

openssl req -new -key ca.pem -out ca.csr -config ca_openssl.cnf

-config ca_openssl.cnf：这个选项指定 OpenSSL 使用的配置文件，来指定 CSR 的各个属性。

ca_openssl.cnf内容如下:

[req]
distinguished_name = req_distinguished_name
req_extensions = ext

[req_distinguished_name]
organizationName = Organization Name (eg, company)
organizationName_default = Self Sign
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Self Sign CA
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = Self Sign

[ext]
keyUsage = critical,keyCertSign,cRLSign
basicConstraints = critical,CA:TRUE

3.生成自签根证书

openssl-x509文档:https://www.openssl.org/docs/man3.0/man1/openssl-x509.html

使用以下命令生成根证书:

如果生成的证书签名请求使用的是纯命令行的形式，则使用下面的命令签署：

openssl x509 -req -days 365 -in ca.csr -signkey ca.pem -out ca.crt -copy_extensions copy

-signkey(key的别名) ca.pem：这个选项指定用于签署证书的私钥文件的路径。

-copy_extensions copy：这个选项指定将 CSR 中的扩展属性复制到生成的证书中。

如果使用的是配置文件的方式，则使用下面的命令：

openssl x509 -req -days 365 -in ca.csr -signkey ca.pem -out ca.crt -config ca_openssl.cnf -extensions ext

稍后你将使用此证书来为服务器证书签名

创建服务器证书

1.创建服务器 RSA 私钥

openssl genpkey -algorithm RSA -out server.pem -pkeyopt rsa_keygen_bits:2048

2.创建 CSR（证书签名请求）

CSR 是请求证书时向 CA 提供的公钥。 CA 将针对此特定请求颁发证书。

服务器证书的 CN 必须与颁发者的域不同。例如，在本例中，颁发者的 CN 是 Self Sign，服务器证书的 CN 是 localhost

注意: 本例是在本地运行服务的，所以subjectAltName可以配置为subjectAltName = DNS:localhost,IP:127.0.0.1,IP:127.0.0.2，如果你的服务不是运行在本地，而是其他域名或者IP的情况下需要根据你的情况修改，比如：

你的服务器IP为192.168.199.151，需要修改成为subjectAltName = IP:192.168.199.151
或者你使用的是域名，则需要修改成你自己的域名subjectAltName = DNS:example.com

命令1：

openssl req -new -key server.pem -out server.csr -subj “/C=CN/ST=Beijing/L=Beijing/O=local/OU=local/CN=localhost” -addext “subjectAltName = DNS:localhost,IP:127.0.0.1,IP:127.0.0.2”

或者

命令2：

openssl req -new -key server.pem -out server.csr -config openssl.cnf

openssl.cnf

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = CN
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Beijing
localityName = Locality Name (eg, city)
localityName_default = Beijing
organizationName = Organization Name (eg, company)
organizationName_default = local
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = local
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = localhost

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1
IP.2 = 127.0.0.2

注意：RFC 2818描述了匹配域名与证书的两种方法：使用subjectAlternativeName扩展中可用的名称，或在缺少SAN扩展的情况下回退到commonName。回退到commonName已经在RFC 2818（2000年发布）中被弃用，但许多TLS客户端仍然支持这种方式,通常还存在错误。

使用subjectAlternativeName 字段,可以明确证书是否表达对IP地址或者域名的绑定,并完全符合Name Constraints定义。但是commonName 是不明确的,正因为如此,基于它的支持已成为Chrome、它使用的库以及TLS生态系统中的安全BUG来源。

废弃commonName 而带来的兼容性风险很低。RFC 2818 已经弃用它近两十年了,最低要求（所有公开信任的证书颁发机构必须遵守）自2012年以来要求存在subjectAltName。自Firefox 48以来，Firefox已经要求所有新颁发的公开信任证书必须包含subjectAltName。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。