如何为本地主机创建自签名证书？

我使用密码并将以下字段设置为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/

服务器测试操作系统：Debian 8.5。
服务器：Raspberry Pi 3b。Owncloud服务器：8.2.5。Owncloud客户端：2.1.1。系统客户端：Debian 8.5。

openssl req -x509-天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，并通过传递给OpenSSL命令-config example-com.conf。

同时注意哦：所有机器算得上是localhost，localhost.localdomain等要小心为其颁发证书localhost。我并不是说不要这样做；只要了解其中涉及一些风险即可。

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

浏览器仍会向您发出有关未链接回受信任根的自签名证书的警告。诸如curland 这样的工具wget不会抱怨，但是您仍然需要使用cURL's之类的选项来信任您的自签名--cafile。要克服浏览器信任问题，您必须成为自己的CA。

“成为自己的CA”被称为运行专用PKI。没什么。您可以做公共CA可以做的所有事情。唯一一点不同的是，你需要安装你的根CA证书在各个门店。就像使用cURL一样cacerts.pm。cacerts.pm只是Root 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可能会抱怨“ 通用名称”无效（ERR_CERT_COMMON_NAME_INVALID）。我不确定在这种情况下，SAN中的IP地址和CN之间的关系是什么。

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

在CommonName应与任何被发送作为对应Host: 于HTTP请求头。在您的情况下，这将是192.168.1.107 （不带斜杠）。

配置Web服务器的主机名

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

ServerName owncloud.masi

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

192.168.1.107   owncloud.masi