具有扩展密钥用法的证书仅在Firefox中有效 [英] Certificate with Extended Key Usage only works in Firefox
问题描述
我试图为我的服务器生成多个域的自签名证书.我使用基于v3_req扩展名的openssl. 我使用此命令行来生成具有多个域和扩展密钥用法的证书:
I tried to generate a self-sign certificate to my server for multiple domains. I used openssl basing in v3_req extension. I used this command line to generate certificate with multiple domain and extended key usage:
openssl x509 -req -days 3650 -in san_domain_com.csr -signkey san_domain_com.key -out san_domain_com.crt -extensions v3_req -extensions mysection -extfile openssl.cnf
结果是我的证书包含多个域，但不包含serverauth和clientauth的扩展密钥用法，而且我的网站只能从Firefox访问. 有人对此有想法吗? 谢谢
It's result that my certificate contains the multiple domain but not the extended Key Usage for serverauth and the clientauth also my website is only accessible from Firefox. Does someone have idea about this? Thank you
我的openssl.conf文件的结构如下:
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
streetAddress = 2.5.4.9
postalCode = 2.5.4.17
POBox = 2.5.4.18
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
default_md = sha1
distinguished_name = req_distinguished_name
req_extensions = v3_req
#attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Nom du pays (code ISO a 2 lettres)
countryName_default = FR
countryName_min = 2
countryName_max = 2
stateOrProvinceName = Nom du departement
stateOrProvinceName_default = Alpes Maritimes
stateOrProvinceName_max = 64
localityName = Nom de la ville
localityName_default = Nice
localityName_max = 64
organizationName = Raison Sociale (nom officiel de l organisation)
organizationName_default = Michel Durand SA
organizationName_max = 64
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Nom commercial, service, ou texte libre (optionnel)
organizationalUnitName_default = Fourni par TBS internet
organizationalUnitName_max = 64
commonName = Adresse du site a securiser (FQDN de votre site)
commonName_default = www.monsitessl.fr
commonName_max = 64
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = abc.bce.com
DNS.2 = abc.bced.com
DNS.3 = abc.bced.com
[ mysection ]
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
推荐答案
有人对此有想法吗?
Does someone have idea about this?
浏览器参加CA/浏览器论坛.另一方是公共CA.有人称它们为卡特尔".浏览器具有称为浏览器安全性模型"或"Web应用程序安全性模型"的安全性模型.在此安全模型中，使用了预定义的受信任锚点的集合.
The Browser participate in the CA/Browsers Forum. The other party is the Public CAs. Some call them "the cartel". Browsers have a security model called the "browser security model" or the "web app security model". In this security model, a collection of predefined trusted anchor point are used.
卡特尔希望终端实体(服务器)证书由浏览器随身携带的受信任存储区中的公共CA签署.由于Chromium使用操作系统的信任存储，因此有些人会放弃随身携带".
The cartel expects end-entity (server) certificates to be signed by a public CA in the trusted store that the browsers carry around with them. There's some hand waiving with "carry around" because Chromium uses the Operating System's trust store.
我希望您可能没有为要测试的其他浏览器正确安装自签名证书.
I expect you probably did not install the self-signed certificate properly for the other browsers you are testing.
您没有向我们显示给您造成麻烦的证书，因此我们只能推测其格式是否正确或有效.但是，我将尝试回答您有关密钥用法和扩展密钥用法的问题.
You did not show us the certificate that's causing you trouble, so we can only speculate if its well formed or valid. But I'll try to answer your question on Key Usage and Extended Key Usage.
我的openssl.conf文件的结构如下...
My openssl.conf file was structured like this...
[ mysection ]
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
这是一个奇怪的组合.你在用吗?如果是这样，您为什么要使用它? (如果您发布证书，将会很有帮助.)
This is an odd combination. Are you using it? If so, why are you using it? (It would be helpful if you posted your certificate).
下面是来自Google，Microsoft和Yahoo的证书.他们的服务器证书 不包括代码签名，并且还包含一些其他用法.
Below are some greps of certificates from Google, Microsoft and Yahoo. Their server certificates do not include code signing, and they include some additional usage.
$ 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中有效...
Certificate with Extended Key Usage only works in Firefox...
根据 RFC 5280 ，扩展密钥用法是可选的.另一个标准是 CA/Browser论坛基准要求，以及大多数公众使用的政策CA颁发证书.我不能说出CA/B BR关于最终实体证书的说法，因为它是如此令人困惑.
According to RFC 5280, Extended Key Usage is optional. The other standard is the CA/Browser Forums Baseline Requirements, and its the policy used by most Public CAs to issue certificates. I can't tell what the CA/B BR says about it with respect to end entity certs because it so confusing.
密钥用法
Key Usage
首先，RSA证书的密钥用法通常为digitalSignature和keyEncipherment.
First, the Key Usage for RSA certificates is usually digitalSignature and keyEncipherment.
如果您具有带有Diffie-Hellman参数的证书，则可以使用keyAgreement.我从未见过使用Diffie-Hellman签名(我认为这是ElGamal签名)，所以我不相信带有Diffie-Hellman参数的证书应该包含digitalSignature.
If you have a certificate with Diffie-Hellman parameters, then you would use keyAgreement. I've never seen signatures with Diffie-Hellman (I think that's ElGamal signing), so I don't believe a cert with Diffie-Hellman parameters should include digitalSignature.
您不应该使用dataEncipherment，因为您不想使用密钥进行批量加密；因此，请不要使用dataEncipherment.相反，您仅只想传输用于批量加密的密钥(与keyEncipherment相对).
You should not use dataEncipherment because you don't want to do bulk encryption with the key; rather you only want to transport a key that's used for bulk encryption (vis-à-vis keyEncipherment).
nonRepudiation没什么用，所以请不要使用它.
And nonRepudiation means nothing, so don't use it.
扩展密钥用法
Extended Key Usage
其次，RFC状态(在第4.2.1.12节中):"[[EKU]指示除了或代替本标准中指定的基本用途之外，还可使用经认证的公钥的一种或多种目的.密钥用法扩展" .在 CA/Browser论坛基准要求下，我 认为 > 扩展密钥用法对于最终实体证书是可选的.我只能说我认为"，因为附录(B)(3)(G)令人困惑.我相当确定，从属CA证书必须使用EKU.
Second, the RFCs state (in Section 4.2.1.12): "[EKU] indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension". Under the CA/Browser Forums Baseline Requirements, I think Extended Key Usage is optional for end entity certificates. I can only say "I think" because Appendix (B)(3)(G) is confusing. I'm fairly certain EKU is mandatory for Subordinate CA certificates, though.
因为我将扩展密钥用法视为可选属性，所以通常将其忽略.如果要包含它，我会使用serverAuth，可能还会使用clientAuth(它们应该是互斥的，但是我经常会在证书中看到它们).
Because I treat Extended Key Usage an optional attribute, I usually omit it. If I were going to include it, I would use serverAuth and possibly clientAuth (they should be mutually exclusive, but I often see them both in a certificate).
配置文件
Configuration File
这是我用于生成用于测试的自签名证书的CONF文件.它是最小的，并且不包括OpenSSL配置文件中的多余部分.我从没有在库或浏览器中遇到过问题.
Here's the CONF file I use for generating self-signed certificates for testing. Its minimal, and does not include the extra sections from OpenSSL's configuration file. I've never had a problem with it in libraries or browsers.
您将必须取消注释# extendedKeyUsage = serverAuth, clientAuth并对其进行修改以适合您的口味.
You will have to uncomment # extendedKeyUsage = serverAuth, clientAuth and modify it to suit your taste.
# 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 = 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
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
这篇关于具有扩展密钥用法的证书仅在Firefox中有效的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
