您如何与证书颁发机构签署证书签名请求? [英] How do you sign a Certificate Signing Request with your Certification Authority?
问题描述
在搜索过程中，我发现了几种签署SSL证书签名请求的方法:
During my search, I found several ways of signing a SSL Certificate Signing Request:
-
使用
x509模块:
openssl x509 -req -days 360 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt
使用ca模块:
openssl ca -cert ca.crt -keyfile ca.key -in server.csr -out server.crt
注意:我不确定对于此参数使用正确的参数.如果我要使用它，请告知正确的用法.
Note: I am unsure of the use of the right parameters for this one. Please advise correct usage if I am to use it.
应该使用哪种方式与您的证书颁发机构签署证书申请? 一种方法是否比另一种更好(例如，一种方法已被弃用)?
What way should one use to sign certificate requests with your Certification Authority? Is one method better than the other (for example, one being deprecated)?
推荐答案
1. Using the x509 module
openssl x509 ...
...
2 Using the ca module
openssl ca ...
...
您错过了这些命令的前奏.
You are missing the prelude to those commands.
这是一个两步过程.首先，您需要设置CA，然后签署最终实体证书(也就是服务器或用户).这两个命令都将这两个步骤合而为一.两者都假定您已经为CA和服务器(终端实体)证书设置了一个OpenSSL配置文件.
This is a two-step process. First you set up your CA, and then you sign an end entity certificate (a.k.a server or user). Both of the two commands elide the two steps into one. And both assume you have a an OpenSSL configuration file already setup for both CAs and Server (end entity) certificates.
首先，创建一个基本的配置文件:
First, create a basic configuration file:
$ touch openssl-ca.cnf
然后，向其中添加以下内容:
Then, add the following to it:
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
[ CA_default ]
default_days = 1000 # How long to certify for
default_crl_days = 30 # How long before next CRL
default_md = sha256 # Use public key default MD
preserve = no # Keep passed DN ordering
x509_extensions = ca_extensions # The extensions to add to the cert
email_in_dn = no # Don't concat the email in the DN
copy_extensions = copy # Required to copy SANs from CSR to cert
####################################################################
[ req ]
default_bits = 4096
default_keyfile = cakey.pem
distinguished_name = ca_distinguished_name
x509_extensions = ca_extensions
string_mask = utf8only
####################################################################
[ ca_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Maryland
localityName = Locality Name (eg, city)
localityName_default = Baltimore
organizationName = Organization Name (eg, company)
organizationName_default = Test CA, Limited
organizationalUnitName = Organizational Unit (eg, division)
organizationalUnitName_default = Server Research Department
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test CA
emailAddress = Email Address
emailAddress_default = test@example.com
####################################################################
[ ca_extensions ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer
basicConstraints = critical, CA:true
keyUsage = keyCertSign, cRLSign
以上字段取自更复杂的openssl.cnf(您可以在/usr/lib/openssl.cnf中找到)，但我认为它们是创建CA证书和私钥的必要条件.
The fields above are taken from a more complex openssl.cnf (you can find it in /usr/lib/openssl.cnf), but I think they are the essentials for creating the CA certificate and private key.
调整上面的字段以适合您的口味.使用默认值可以节省您在尝试配置文件和命令选项时输入相同信息的时间.
Tweak the fields above to suit your taste. The defaults save you the time from entering the same information while experimenting with configuration file and command options.
我省略了与CRL有关的内容，但您的CA操作应具有它们.请参阅openssl.cnf和相关的crl_ext部分.
I omitted the CRL-relevant stuff, but your CA operations should have them. See openssl.cnf and the related crl_ext section.
然后，执行以下操作. -nodes省略了密码或密码短语，因此您可以检查证书.忽略密码或密码短语是确实 不好的想法.
Then, execute the following. The -nodes omits the password or passphrase so you can examine the certificate. It's a really bad idea to omit the password or passphrase.
$ openssl req -x509 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM
命令执行后，cacert.pem将是您进行CA操作的证书，而cakey.pem将是私钥.回忆私钥 没有密码或密码.
After the command executes, cacert.pem will be your certificate for CA operations, and cakey.pem will be the private key. Recall the private key does not have a password or passphrase.
您可以使用以下内容转储证书.
You can dump the certificate with the following.
$ openssl x509 -in cacert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11485830970703032316 (0x9f65de69ceef2ffc)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test@example.com
Validity
Not Before: Jan 24 14:24:11 2014 GMT
Not After : Feb 23 14:24:11 2014 GMT
Subject: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:b1:7f:29:be:78:02:b8:56:54:2d:2c:ec:ff:6d:
...
39:f9:1e:52:cb:8e:bf:8b:9e:a6:93:e1:22:09:8b:
59:05:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A
X509v3 Authority Key Identifier:
keyid:4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
4a:6f:1f:ac:fd:fb:1e:a4:6d:08:eb:f5:af:f6:1e:48:a5:c7:
...
cd:c6:ac:30:f9:15:83:41:c1:d1:20:fa:85:e7:4f:35:8f:b5:
38:ff:fd:55:68:2c:3e:37
并使用以下命令测试其目的(不必担心Any Purpose: Yes；请参阅).
And test its purpose with the following (don't worry about the Any Purpose: Yes; see "critical,CA:FALSE" but "Any Purpose CA : Yes").
$ openssl x509 -purpose -in cacert.pem -inform PEM
Certificate purposes:
SSL client : No
SSL client CA : Yes
SSL server : No
SSL server CA : Yes
Netscape SSL server : No
Netscape SSL server CA : Yes
S/MIME signing : No
S/MIME signing CA : Yes
S/MIME encryption : No
S/MIME encryption CA : Yes
CRL signing : Yes
CRL signing CA : Yes
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : Yes
Time Stamp signing : No
Time Stamp signing CA : Yes
-----BEGIN CERTIFICATE-----
MIIFpTCCA42gAwIBAgIJAJ9l3mnO7y/8MA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
...
aQUtFrV4hpmJUaQZ7ySr/RjCb4KYkQpTkOtKJOU1Ic3GrDD5FYNBwdEg+oXnTzWP
tTj//VVoLD43
-----END CERTIFICATE-----
对于第二部分，我将创建另一个易于消化的配置文件.首先，touch openssl-server.cnf(您也可以为用户证书创建其中之一).
For part two, I'm going to create another configuration file that's easily digestible. First, touch the openssl-server.cnf (you can make one of these for user certificates also).
$ touch openssl-server.cnf
然后打开它，并添加以下内容.
Then open it, and add the following.
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ req ]
default_bits = 2048
default_keyfile = serverkey.pem
distinguished_name = server_distinguished_name
req_extensions = server_req_extensions
string_mask = utf8only
####################################################################
[ server_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = MD
localityName = Locality Name (eg, city)
localityName_default = Baltimore
organizationName = Organization Name (eg, company)
organizationName_default = Test Server, Limited
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test Server
emailAddress = Email Address
emailAddress_default = test@example.com
####################################################################
[ server_req_extensions ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
####################################################################
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
如果您正在开发并且需要将工作站用作服务器，则可能需要对Chrome执行以下操作.否则 Chrome可能会投诉公用名无效(ERR_CERT_COMMON_NAME_INVALID).我不确定在这种情况下，SAN中的IP地址和CN之间的关系是什么.
If you are developing and need to use your workstation as a server, then you may need to do the following for Chrome. Otherwise Chrome may complain a Common Name is invalid (ERR_CERT_COMMON_NAME_INVALID). I'm not sure what the relationship is between an IP address in the SAN and a CN in this instance.
# IPv4 localhost
IP.1 = 127.0.0.1
# IPv6 localhost
IP.2 = ::1
然后，创建服务器证书请求.请确保省略 -x509 *.添加-x509将创建证书，而不是请求.
Then, create the server certificate request. Be sure to omit -x509*. Adding -x509 will create a certificate, and not a request.
$ openssl req -config openssl-server.cnf -newkey rsa:2048 -sha256 -nodes -out servercert.csr -outform PEM
执行此命令后，您将在servercert.csr中有一个请求，在serverkey.pem中有一个私钥.
After this command executes, you will have a request in servercert.csr and a private key in serverkey.pem.
您可以再次检查它.
$ openssl req -text -noout -verify -in servercert.csr
Certificate:
verify OK
Certificate Request:
Version: 0 (0x0)
Subject: C=US, ST=MD, L=Baltimore, CN=Test Server/emailAddress=test@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d:
...
f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51:
86:e1
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Key Identifier:
1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
6d:e8:d3:85:b3:88:d4:1a:80:9e:67:0d:37:46:db:4d:9a:81:
...
76:6a:22:0a:41:45:1f:e2:d6:e4:8f:a1:ca:de:e5:69:98:88:
a9:63:d0:a7
下一步，您必须使用CA对其进行签名.
Next, you have to sign it with your CA.
您几乎已经准备好通过CA签署服务器的证书. CA的openssl-ca.cnf在发出命令之前还需要另外两个部分.
You are almost ready to sign the server's certificate by your CA. The CA's openssl-ca.cnf needs two more sections before issuing the command.
首先，打开openssl-ca.cnf并添加以下两个部分.
First, open openssl-ca.cnf and add the following two sections.
####################################################################
[ signing_policy ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ signing_req ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
第二，将以下内容添加到openssl-ca.cnf的[ CA_default ]部分.我把它们排除在外，因为它们会使事情复杂化(当时它们还没有使用).现在，您将看到它们的用法，希望它们会有意义.
Second, add the following to the [ CA_default ] section of openssl-ca.cnf. I left them out earlier, because they can complicate things (they were unused at the time). Now you'll see how they are used, so hopefully they will make sense.
base_dir = .
certificate = $base_dir/cacert.pem # The CA certifcate
private_key = $base_dir/cakey.pem # The CA private key
new_certs_dir = $base_dir # Location for new certs after signing
database = $base_dir/index.txt # Database index file
serial = $base_dir/serial.txt # The current serial number
unique_subject = no # Set to 'no' to allow creation of
# several certificates with same subject.
第三，触摸index.txt和serial.txt:
$ touch index.txt
$ echo '01' > serial.txt
然后，执行以下操作:
$ openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out servercert.pem -infiles servercert.csr
您应该看到类似以下内容的内容:
You should see similar to the following:
Using configuration from openssl-ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :ASN.1 12:'MD'
localityName :ASN.1 12:'Baltimore'
commonName :ASN.1 12:'Test CA'
emailAddress :IA5STRING:'test@example.com'
Certificate is to be certified until Oct 20 16:12:39 2016 GMT (1000 days)
Sign the certificate? [y/n]:Y
1 out of 1 certificate requests certified, commit? [y/n]Y
Write out database with 1 new entries
Data Base Updated
命令执行后，您将在servercert.pem中拥有一个新鲜的服务器证书.私钥是先前创建的，可在serverkey.pem中使用.
After the command executes, you will have a freshly minted server certificate in servercert.pem. The private key was created earlier and is available in serverkey.pem.
最后，您可以使用以下方法检查新鲜铸造的证书:
Finally, you can inspect your freshly minted certificate with the following:
$ openssl x509 -in servercert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test@example.com
Validity
Not Before: Jan 24 19:07:36 2014 GMT
Not After : Oct 20 19:07:36 2016 GMT
Subject: C=US, ST=MD, L=Baltimore, CN=Test Server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d:
...
f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51:
86:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61
X509v3 Authority Key Identifier:
keyid:42:15:F2:CA:9C:B1:BB:F5:4C:2C:66:27:DA:6D:2E:5F:BA:0F:C5:9E
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
b1:40:f6:34:f4:38:c8:57:d4:b6:08:f7:e2:71:12:6b:0e:4a:
...
45:71:06:a9:86:b6:0f:6d:8d:e1:c5:97:8d:fd:59:43:e9:3c:
56:a5:eb:c8:7e:9f:6b:7a
之前，您已将以下内容添加到CA_default:copy_extensions = copy.这将复制提出请求的人提供的扩展名.
Earlier, you added the following to CA_default: copy_extensions = copy. This copies extension provided by the person making the request.
如果省略copy_extensions = copy，则服务器证书将缺少主题备用名称(SAN)，例如www.example.com和mail.example.com.
If you omit copy_extensions = copy, then your server certificate will lack the Subject Alternate Names (SANs) like www.example.com and mail.example.com.
如果您使用copy_extensions = copy，但不查看请求，那么请求者可能会欺骗您签署诸如从属根目录(而不是服务器或用户证书)之类的内容.这意味着他/她将能够铸造链接回您受信任的根的证书.在签名之前，请务必使用openssl req -verify验证请求.
If you use copy_extensions = copy, but don't look over the request, then the requester might be able to trick you into signing something like a subordinate root (rather than a server or user certificate). Which means he/she will be able to mint certificates that chain back to your trusted root. Be sure to verify the request with openssl req -verify before signing.
如果省略 unique_subject或将其设置为yes，则只允许您以受试者的专有名称创建一个证书.
If you omit unique_subject or set it to yes, then you will only be allowed to create one certificate under the subject's distinguished name.
unique_subject = yes # Set to 'no' to allow creation of
# several ctificates with same subject.
尝试在尝试创建第二个证书时，使用CA的私钥对服务器的证书签名会导致以下结果:
Trying to create a second certificate while experimenting will result in the following when signing your server's certificate with the CA's private key:
Sign the certificate? [y/n]:Y
failed to update database
TXT_DB error number 2
所以unique_subject = no非常适合测试.
如果要确保自签名CA，从属CA 和最终实体证书之间的组织名称一致，则添加将以下内容添加到您的CA配置文件中:
If you want to ensure the Organizational Name is consistent between self-signed CAs, Subordinate CA and End-Entity certificates, then add the following to your CA configuration files:
[ policy_match ]
organizationName = match
如果要允许更改组织名称，请使用:
If you want to allow the Organizational Name to change, then use:
[ policy_match ]
organizationName = supplied
还有其他有关X.509/PKIX证书中DNS名称处理的规则.有关规则，请参阅这些文档:
There are other rules concerning the handling of DNS names in X.509/PKIX certificates. Refer to these documents for the rules:
- RFC 5280， Internet X.509公钥基础结构证书和证书吊销列表(CRL)配置文件
- RFC 6125，使用X.509在Internet公钥基础结构中表示和验证基于域的应用程序服务身份传输层安全性(TLS)上下文中的(PKIX)证书
- RFC 6797，附录A， HTTP严格传输安全性(HSTS)
- RFC 7469， HTTP的公钥固定扩展
- CA/浏览器论坛基准要求
- CA/浏览器论坛扩展的验证准则
- RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
- RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
- RFC 6797, Appendix A, HTTP Strict Transport Security (HSTS)
- RFC 7469, Public Key Pinning Extension for HTTP
- CA/Browser Forum Baseline Requirements
- CA/Browser Forum Extended Validation Guidelines
列出了RFC 6797和RFC 7469，因为它们比其他RFC和CA/B文档更具限制性. RFC的6797和7469也不允许IP地址.
RFC 6797 and RFC 7469 are listed, because they are more restrictive than the other RFCs and CA/B documents. RFC's 6797 and 7469 do not allow an IP address, either.
这篇关于您如何与证书颁发机构签署证书签名请求?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
