我以 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: [email protected]
输出:HTTPS 中的 SSL 握手错误。预期输出:HTTPS 连接。 HTTP 有效。
CommonName 应该包含你想去的 URL,owncloud 的线程这里。我在 commonname 中尝试失败
192.168.1.107/owncloud
192.168.1.107/
服务器测试操作系统:Debian 8.5。
服务器:树莓派 3b。自己的云服务器:8.2.5。自己的云客户端:2.1.1。系统客户端:Debian 8.5。
答案1
openssl req -x509 -days 365 -newkey rsa:2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt
您无法使用此命令生成格式良好的 X.509 证书。它将出现格式错误,因为主机名被放置在通用名(中文)。 IETF(大多数工具,如wget
和curl
)和 CA/B 论坛(CA 和浏览器)均不赞成在 CN 中放置主机名或 IP 地址。
根据 IETF 和 CA/B 论坛,服务器名称和 IP 地址始终位于主题备用名称 (SAN)。规则请参见RFC 5280、Internet X.509 公钥基础设施证书和证书吊销列表 (CRL) 配置文件和CA/浏览器论坛基准要求。
您主要需要使用 OpenSSL 配置文件并对其进行定制以满足您的需求。下面是我使用的一个示例。它被称为example-com.conf
,并通过 传递给 OpenSSL 命令-config example-com.conf
。
还好好注意:所有机器都声称是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 = [email protected]
# 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
答案2
应与 HTTP 请求中CommonName
作为标头发送的内容相对应。Host:
在你的情况下,那就是192.168.1.107
(没有尾部斜杠)。
配置 Web 服务器的主机名
就个人而言,我会为 Web 服务器配置一个友好的主机名。在您的邮件 Apache 配置或虚拟主机配置(可能位于
/etc/apache2/sites-enabled/000-default.conf
基于 Debian 的发行版)中,使用ServerName
或ServerAlias
指令,例如,
ServerName owncloud.masi
重新启动 Apache,然后配置 DNS 或(更简单地)在每个客户端中添加一个条目/etc/hosts
以将其指向正确的 IP 地址,例如,
192.168.1.107 owncloud.masi