有人对此有想法吗?
浏览器参与 CA/浏览器论坛。另一方是公共 CA。有人称他们为“卡特尔”。浏览器有一个安全模型,称为“浏览器安全模型”或“Web 应用程序安全模型”。在此安全模型中,使用预定义的可信锚点的集合。
卡特尔希望终端实体(服务器)证书由浏览器随身携带的受信任存储中的公共 CA 进行签名。由于 Chromium 使用操作系统的信任存储,因此“随身携带”有一些麻烦。
我预计您可能没有为您正在测试的其他浏览器正确安装自签名证书。
您没有向我们展示给您带来麻烦的证书,因此我们只能推测其格式是否正确或有效。但我会尝试回答您有关密钥用法和扩展密钥用法的问题。
我的 openssl.conf 文件的结构如下......
[ mysection ]
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
这是一个奇怪的组合。你在用它吗?如果是这样,你为什么要使用它? (如果您发布了您的证书,将会很有帮助)。
下面是一些来自 Google、Microsoft 和 Yahoo 的证书的 grep。他们的服务器证书do not包括代码签名,并且它们包括一些额外的用法。
$ openssl s_client -connect www.google.com:443 | openssl x509 -text -noout | grep -A 1 -i key
...
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
--
X509v3 Subject Key Identifier:
30:11:ED:AE:FE:C3:60:32:1D:CF:9C:B7:4B:B4:E3:DD:2D:1D:FC:40
--
X509v3 Authority Key Identifier:
keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
$ openssl s_client -connect www.microsoft.com:443 | openssl x509 -text -noout | grep -A 1 -i key
...
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
--
X509v3 Subject Key Identifier:
2B:DB:4A:3F:90:02:48:9E:0F:89:21:E2:EB:4A:73:1E:E0:0F:85:6B
--
X509v3 Authority Key Identifier:
keyid:EB:DB:11:5E:F8:09:9E:D8:D6:62:9C:FD:62:9D:E3:84:4A:28:E1:27
$ openssl s_client -connect www.yahoo.com:443 | openssl x509 -text -noout | grep -A 1 -i key
...
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
--
X509v3 Authority Key Identifier:
keyid:0D:44:5C:16:53:44:C1:82:7E:1D:20:AB:25:F4:01:63:D8:BE:79:A5
具有扩展密钥用法的证书仅适用于 Firefox...
根据RFC 5280,扩展密钥使用是可选的。另一个标准是CA/浏览器论坛基准要求,这是大多数公共 CA 用来颁发证书的策略。我不知道 CA/B BR 关于最终实体证书的说法,因为它太令人困惑了。
按键用法
首先,RSA证书的密钥用法通常是digitalSignature
and keyEncipherment
.
如果您有带有 Diffie-Hellman 参数的证书,那么您可以使用keyAgreement
。我从未见过 Diffie-Hellman 签名(我认为这是 ElGamal 签名),所以我不认为具有 Diffie-Hellman 参数的证书应该包括digitalSignature
.
你不应该使用dataEncipherment
因为你不想用密钥进行批量加密;而是你only想要传输用于批量加密的密钥(相对于keyEncipherment
).
And nonRepudiation
没有任何意义,所以不要使用它。
扩展密钥用法
其次,RFC 规定(第 4.2.1.12 节):“[EKU] 表示除了密钥使用扩展中指示的基本目的之外或代替密钥使用扩展中指示的基本目的之外,还可以使用经过认证的公钥的一个或多个目的”。在下面CA/浏览器论坛基准要求, I think对于最终实体证书来说,扩展密钥用法是可选的。我只能说“我认为”,因为附录(B)(3)(G)令人困惑。不过,我相当肯定 EKU 对于从属 CA 证书是强制性的。
因为我将扩展密钥用法视为可选属性,所以我通常会忽略它。如果我要包含它,我会使用serverAuth
并且可能clientAuth
(它们应该是互斥的,但我经常在证书中看到它们)。
配置文件
这是我用来生成用于测试的自签名证书的 CONF 文件。它是最小的,并且不包括 OpenSSL 配置文件中的额外部分。我在库或浏览器中从未遇到过问题。
您必须取消注释# extendedKeyUsage = serverAuth, clientAuth
并修改它以适合您的口味。
# Self Signed (note the addition of -x509):
# openssl req -config example-com.conf -new -x509 -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).
# 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 its 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.
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
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