我正在为一个嵌入式Linux设备添加HTTPS支持。我尝试使用以下步骤生成自签名证书：
openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem
这个方案是可行的，但在使用 Google Chrome 等浏览器时出现了一些错误：
这可能不是您正在寻找的网站！
网站的安全证书不受信任！
我是否漏掉了什么？这是构建自签名证书的正确方式吗？
你可以用一条命令完成这个操作：
# interactive
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365
# non-interactive and 10 years expiration
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
如果你不想用密码保护你的私钥，你还可以添加-nodes（即"no DES"的缩写）。否则它会提示你输入至少4个字符的密码。
days参数（365）可以替换为任何数字以影响到期日期。然后它会提示你输入"Country Name"等信息，但你可以直接按下Enter键并接受默认值。
添加-subj '/CN=localhost'以避免询问证书内容（将localhost替换为你想要的域名）。
自签名证书在未导入浏览器之前不会经过任何第三方验证。如果你需要更高的安全性，应该使用由证书颁发机构（CA）签名的证书。
-subj "/C=US/ST=Oregon/L=Portland/O=Company Name/OU=Org/CN=www.example.com"。 - Alex Sopenssl req -x509 -newkey rsa:4096 -sha256 -days 3650 \
-nodes -keyout example.com.key -out example.com.crt -subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:10.0.0.1"
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 -days 3650 \
-nodes -keyout example.com.key -out example.com.crt -subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:10.0.0.1"
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 \
-nodes -keyout example.com.key -out example.com.crt -extensions san -config \
<(echo "[req]";
echo distinguished_name=req;
echo "[san]";
echo subjectAltName=DNS:example.com,DNS:*.example.com,IP:10.0.0.1
) \
-subj "/CN=example.com"
example.com（SAN）有效，
- 对于通配符域名*.example.com（SAN）也有效，
- 对于IP地址10.0.0.1（SAN）也有效，
- 相对强大（截至2023年）并且
- 有效期为3650天（约10年）。example.com.key
- 证书：example.com.crt
所有信息都在命令行提供。没有让您烦恼的交互式输入。没有需要处理的配置文件。所有必要的步骤都由单个OpenSSL调用执行：从私钥生成到自签名证书。
由于证书是自签名的，需要用户手动接受，因此使用短期过期或弱密码学是没有意义的。
在将来，您可能希望为RSA密钥使用超过4096位，并且使用比sha256更强大的哈希算法，但截至2023年，这些值是合理的。它们足够强大，同时又得到了所有现代浏览器的支持。
-nodes"理论上，您可以省略-nodes参数（表示"无DES加密"），在这种情况下，example.key将使用密码进行加密。然而，对于服务器安装来说，这几乎从不有用，因为您要么必须将密码存储在服务器上，要么每次重新启动时都必须手动输入密码。
$ openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout localhost.key -out localhost.crt -subj '/CN=localhost' -addext subjectAltName=DNS:localhost,IP:127.0.0.1
生成RSA私钥
[...]
将新私钥写入 'localhost.key'
-----
名称应该符合格式/type0=value0/type1=value1/type2=...，其中字符可以通过\进行转义。但是该名称不符合此格式：'C:/Program Files/Git/CN=localhost'
出现制作证书请求时的问题 - Yuri Pozniak/CN=localhost被扩展为C:/Program Files/Git/CN=localhost。如果你添加一个额外的斜杠，那么就不会发生这种扩展了。 //CN=localhost - Dave Ferguson我有所遗漏吗？这是构建自签名证书的正确方法吗？
创建自签名证书很容易，只需使用openssl req命令即可。但要创建一个可以被大多数客户端（如浏览器和命令行工具）接受的证书可能有些棘手。
这很困难，因为浏览器有自己的一套要求，而且它们比IETF更为严格。浏览器使用的要求在CA/Browser Forums中有记录（见下面的参考资料）。限制主要出现在两个关键领域：（1）信任锚点和（2）DNS名称。
现代浏览器（如我们在2014/2015年使用的浏览器）希望证书可以追溯到信任锚点，并且希望DNS名称以特定方式呈现在证书中。而且，浏览器正在积极地反对自签名服务器证书。
某些浏览器并不那么容易导入自签名服务器证书。事实上，像Android的浏览器这样的浏览器根本无法导入。因此，完整的解决方案是成为自己的权威机构。
在没有成为自己的权威机构的情况下，您需要正确获取DNS名称以使证书成功的可能性最大化。但我鼓励您成为自己的权威机构。成为自己的权威机构很容易，并且将避开所有信任问题（谁比你自己更可信呢？）。这可能不是您要找的网站！
该网站的安全证书无法得到信任！
这是因为浏览器使用预定义的信任锚点列表来验证服务器证书。自签名证书无法链接回信任的锚点。
避免此问题的最佳方法是：
步骤1 - 创建自己的授权 意味着使用CA: true和适当的密钥用法创建自签名证书。这意味着主题和颁发者是同一实体，基本限制中设置了CA为true（它也应标记为关键），密钥用法为keyCertSign和crlSign（如果您正在使用CRL），并且主题密钥标识符（SKI）与授权密钥标识符（AKI）相同。
要成为自己的证书颁发机构，请参见Stack Overflow上的*如何使用您的认证机构对证书签名请求进行签名？。然后，将您的CA导入浏览器使用的信任存储中。
步骤2-4大致上是您现在为公共服务器做的事情，当您使用CA（如Startcom或CAcert）的服务时。步骤1和5允许您避免第三方机构，并充当自己的机构（谁比您自己更值得信任？）。subjectAltName = @alternate_names（无法通过命令行完成）。然后，在配置文件中有一个alternate_names部分（您应该调整此部分以适合您的口味）：[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# IP.1 = 127.0.0.1
# IP.2 = ::1
创建自签名证书（注意添加-x509选项）：
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.cert.pem
-x509选项）：openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.req.pem
openssl x509 -in example-com.cert.pem -text -noout
openssl req -in example-com.req.pem -text -noout
-config选项传递）[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test@example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# You only need digitalSignature below. *If* you don't allow
# RSA Key transport (i.e., you use ephemeral cipher suites), then
# omit keyEncipherment because that's key transport.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
ERR_CERT_COMMON_NAME_INVALID)。我不确定SAN中的IP地址与此实例中的CN之间的关系是什么。# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
在X.509/PKIX证书中，还有其他关于处理DNS名称的规则。请参考这些文档以了解规则：
alternate_names 部分中使用通配符是否可行？特别是子域名。 我有一个关于此答案的问题：http://serverfault.com/questions/711596/can-i-use-wildcards-with-san-self-signed-certificates - LeonardChallis以下是@diegows's answer中描述的选项，更详细的信息请参考文档：
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
reqPKCS#10 certificate request and certificate generating utility.
-x509this option outputs a self signed certificate instead of a certificate request. This is typically used to generate a test certificate or a self signed root CA.
-newkey argthis option creates a new certificate request and a new private key. The argument takes one of several forms. rsa:nbits, where nbits is the number of bits, generates an RSA key nbits in size.
-keyout filenamethis gives the filename to write the newly created private key to.
-out filenameThis specifies the output filename to write to or standard output by default.
-days nwhen the -x509 option is being used this specifies the number of days to certify the certificate for. The default is 30 days.
-nodesif this option is specified then if a private key is created it will not be encrypted.
实际上，文档比上面的更详细；我只是在这里进行了总结。
我无法进行评论，因此我将其作为单独的答案发布。我发现这个被接受的一行代码有几个问题：
这里是一个简化版，去掉了口令，提高了安全性以避免警告，并在注释中提供了建议，以传递-subj以删除完整的问题列表：
openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
将“localhost”替换为您需要的域。由于OpenSSL会提示输入密码短语，因此您需要逐个运行前两个命令。
将两个文件合并为.pem文件：
cat server.crt server.key > cert.pem
cat server.crt server.key> foo-cert.pem。适用于 openssl-1.0.2d/demos/ssl/ 中的示例。 - 18446744073709551615server.key 文件是相同的。 - Syed M. Sannan如果自签名证书缺少SAN（主体备用名称），现代浏览器会抛出安全错误，即使证书本身是格式良好的。 OpenSSL没有提供命令行方式来指定SAN，因此许多开发者的教程和书签突然过时了。
最快恢复运行的方法是创建一个短小的独立配置文件：
创建OpenSSL配置文件（例如：req.cnf）
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = www.company.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = company.net
使用此配置文件创建证书
openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
-keyout cert.key -out cert.pem -config req.cnf -sha256
-extension 'subjectAltName = DNS:dom.ain, DNS:oth.er'来指定证书的 SAN 了。请参见 https://github.com/openssl/openssl/pull/4986。 - Alexandre DuBreuil我建议添加-sha256参数，使用SHA-2哈希算法，因为主要浏览器正在考虑将"SHA-1证书"标记为不安全。
与被接受的答案相同的命令行——@diegows，加上了-sha256。
openssl req -x509 -sha256 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
更多信息请参见谷歌安全博客。
更新于2018年5月。正如许多评论中指出的那样，使用SHA-2对于自签名证书并不能增加任何安全性。但还是建议使用它作为一种良好习惯，以避免使用过时/不安全的密码哈希函数。完整的解释可在为什么终端实体证书以上的证书可以基于SHA-1？中找到。
我无法发表评论，因此我添加了一个单独的答案。我尝试为NGINX创建自签名证书，这很容易，但当我想将其添加到Chrome白名单时遇到了问题。我的解决方案是创建一个根证书，并使用它签署一个子证书。
所以逐步进行。 创建文件config_ssl_ca.cnf 注意，配置文件有一个选项basicConstraints = CA：True ，这意味着该证书应该是根证书。
这是一个好习惯，因为您只需创建一次即可重用。
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email@root.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names
下一个用于您的子证书的配置文件将被称为config_ssl.cnf。
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email@market.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash
第一步 - 创建根密钥和证书
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf
第二步是创建子密钥并生成CSR - 证书签名请求文件。因为我们的想法是通过根证书签署子证书并获得正确的证书。
openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr
echo 00 > ca.srl
touch index.txt
ca.srl 文本文件包含下一个要使用的十六进制序列号。 必须存在且包含有效的序列号。
最后一步，创建另一个配置文件并将其命名为config_ca.cnf。
# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca
[ my_ca ]
# a text file containing the next serial number to use in hex. Mandatory.
# This file must be present and contain a valid serial number.
serial = ./ca.srl
# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt
# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./
# the file containing the CA certificate. Mandatory
certificate = ./ca.crt
# the file contaning the CA private key. Mandatory
private_key = ./ca.key
# the message digest algorithm. Remember to not use MD5
default_md = sha256
# for how many days will the signed certificate be valid
default_days = 365
# a section with a set of variables corresponding to DN fields
policy = my_policy
# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy
[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied
你可能想知道，为什么这么难，为什么我们必须创建一个新的配置文件来通过根证书签署子证书。答案很简单，因为子证书必须有一个SAN块 - Subject Alternative Names。
如果我们使用“openssl x509”工具签署子证书，根证书将删除子证书中的SAN字段。
因此，我们使用“openssl ca”而不是“openssl x509”来避免删除SAN字段。我们创建了一个新的配置文件，并告诉它复制所有扩展字段copy_extensions = copy。
openssl ca -config config_ca.cnf -out market.crt -in market.csr
程序会向您询问2个问题：
在终端中，您可以看到一个带有“数据库”一词的句子，它表示您通过命令“touch”创建的文件index.txt。该文件将包含您使用“openssl ca”工具创建的所有证书的信息。 要检查证书是否有效，请使用以下命令：
openssl rsa -in market.key -check
openssl x509 -in market.crt -text -noout
如果您想了解CSR内部情况：
openssl req -in market.csr -noout -text
ca.crt 复制到 ca.pem，执行 cp ca.crt ca.pem 并在 CentOS 上安装 ca.pem 作为受信任的证书颁发机构。现在使用 curl 操作非常完美！要在 CentOS 上安装证书颁发机构，请将 ca.pem 复制到 /etc/pki/ca-trust/source/anchors/，并执行命令 update-ca-trust extract；https://unix.stackexchange.com/a/438698/418196 - atish.sca.crt复制为ca.pem，执行cp ca.crt ca.pem并将ca.pem安装为CentOS上的受信任证书颁发机构。现在使用curl操作非常完美！要在CentOS上安装证书颁发机构，请将ca.pem复制到/etc/pki/ca-trust/source/anchors/目录，并执行命令update-ca-trust extract；https://unix.stackexchange.com/a/438698/418196 - atish.s这是我在本地计算机上使用的脚本，用于设置自签名证书中的SAN（subjectAltName）。
此脚本接受域名（例如example.com），并为*.example.com和example.com生成相同证书中的SAN。下面的部分已经进行了注释。命名该脚本（例如generate-ssl.sh），并赋予可执行权限。文件将被写入与脚本相同的目录中。
Chrome 58及以上版本要求在自签名证书中设置SAN。
#!/usr/bin/env bash
# Set the TLD domain we want to use
BASE_DOMAIN="example.com"
# Days for the cert to live
DAYS=1095
# A blank passphrase
PASSPHRASE=""
# Generated configuration file
CONFIG_FILE="config.txt"
cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn
[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster@$BASE_DOMAIN
CN = $BASE_DOMAIN
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF
# The file name can be anything
FILE_NAME="$BASE_DOMAIN"
# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*
echo "Generating certs for $BASE_DOMAIN"
# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017
openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"
# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"
# Protect the key
chmod 400 "$FILE_NAME.key"
这个脚本还会写入一个信息文件，因此您可以检查新证书并验证SAN是否设置正确。
...
28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
da:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
...
<VirtualHost _default_:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/htdocs
SSLEngine on
SSLCertificateFile path/to/your/example.com.crt
SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>
请记得重新启动您的Apache（或Nginx，或IIS）服务器，以使新证书生效。
localhost或127.0.0.1:port#运行，这种情况下对应的CN是什么？ - DJ22017年度一行代码：
openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
<(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650
/etc/ssl/openssl.conf是有效的。 - declension
alternate_names部分的配置文件，并使用-config选项传递它。同时，在通用名称（CN）中放置DNS名称被IETF和CA/Browser论坛弃用（但不被禁止）。在CN中的任何DNS名称也必须存在于SAN中。无法避免使用SAN。请参见下面的答案。 - jww.com，而是.org。 - Yu Jiaao