如何为本地主机制作自签名证书？

Question

我使用了密码，并使用以下字段作为root

openssl req -x509 -days 365 -newkey rsa:2048 -keyout /etc/ssl/apache.key \
    -out /etc/ssl/apache.crt

字段

Country: FI
State: Pirkanmaa
Locality: Tampere
Organization: masi
Organizational Unit Name: SSL Certificate Test
CommonName: 192.168.1.107/owncloud
EmailAddress: masi@gmail.com

输出: HTTPS中的SSL握手错误。预期输出: HTTPS连接。HTTP有效。

CommonName应该包含您想要访问的URL，即owncloud的线程这里。我曾试过以俗称失败。

• 192.168.1.107/owncloud
• 192.168.1.107/

服务器测试操作系统:Debian8.5。

服务器:覆盆子Pi 3b。Owncloud服务器: 8.2.5。Owncloud-客户机: 2.1.1。系统-客户端: Debian 8.5。

Answer 1

openssl req -x509 -days 365 -newkey rsa:2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt

不能使用此命令生成格式良好的X.509证书。由于主机名被放置在公共名称(CN)中，所以格式会出现错误。IETF (大多数工具，如wget和curl)和CA/B论坛(CA和浏览器)都不推荐在CN中放置主机名或IP地址。

根据IETF和CA/B论坛，服务器名和IP地址总是以主题替换名(SAN)。有关规则，请参见RFC 5280、Internet X.509公钥基础设施证书和证书吊销列表(CRL)配置文件和CA/Browser论坛基线要求。

您通常需要使用一个OpenSSL配置文件，并根据您的需要定制它。下面是我使用的一个例子。它被称为example-com.conf，并通过-config example-com.conf传递给OpenSSL命令。

还要注意:所有机器都声称是localhost、localhost.localdomain等。在为localhost颁发证书时要小心。我不是说不要这么做，只是要明白其中涉及到一些风险。

localhost的替代方案有：(1)运行DNS并向计算机的DNS名称颁发证书。或者，(2)使用静态IP并包含静态IP地址。

浏览器仍然会对不链接到受信任的根的自签名证书发出警告。像curl和wget这样的工具不会抱怨，但是你仍然需要相信你自己签署了一个像cURL的--cafile这样的选项。要克服浏览器信任问题，您必须成为自己的CA。

“成为您自己的CA”被称为运行私有PKI。没什么大不了的。您可以做公共CA所能做的一切。唯一不同的是，您需要在不同的商店中安装根CA证书。它与使用cURL的cacerts.pm没有什么不同。cacerts.pm只是根CA的集合，现在你已经加入了这个俱乐部。

如果您已成为自己的CA，请确保将根CA私钥刻录到磁盘并使其脱机。然后，当您需要签署签名请求时，将其放到您的CD/DVD驱动器中。现在您正在颁发证书，就像颁发公共CA一样。

一旦您签署了一两个签名请求，所有这些都不是非常困难的。我已经在家里开了好几年私人PKI了。我所有的设备和设备都信任我的CA。

有关如何成为自己的CA的更多信息，请参见如何与证书颁发机构签署证书签名请求？和如何使用openssl创建自签名证书？。

从下面配置文件中的注释..。

自签名(注意添加了-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 -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

配置文件

# Self Signed (note the addition of -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
# Signing Request (note the lack of -x509):
#     openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
# Print it:
#     openssl x509 -in example-com.cert.pem -text -noout
#     openssl req -in example-com.req.pem -text -noout

[ 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).
#   It's 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

#  If RSA Key Transport bothers you, then remove keyEncipherment. TLS 1.3 is removing RSA
#  Key Transport in favor of exchanges with Forward Secrecy, like DHE and ECDHE.
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
# 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
# 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
# DNS.9     = fe80::1

您可能需要为Chrome做以下操作。否则，Chrome可能会抱怨Common Name无效(ERR_CERT_COMMON_NAME_INVALID)。我不确定SAN中的IP地址与本例中的CN之间是什么关系。

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Answer 2

CommonName应该与在HTTP请求中作为Host:头发送的任何内容相对应。在您的例子中，这将是192.168.1.107 (没有尾随斜杠)。

为web服务器

配置主机名

就我个人而言，我会为web服务器配置一个友好的主机名。在您的邮件Apache配置或虚拟主机配置中(基于Debian的发行版可能位于/etc/apache2/sites-enabled/000-default.conf )，可以使用ServerName或ServerAlias指令，例如，

ServerName owncloud.masi

重新启动Apache，然后配置DNS或(更简单地说)在每个客户端的/etc/hosts中添加一个条目，将其指向正确的IP地址，例如，

192.168.1.107   owncloud.masi