证书签名请求

一旦生成了私钥，接下来就是创建一个证书签名请求（Certificate Signing Request， CSR）。这是向证书认证机构（CA）请求签署一份证书的正式请求，它包含了请求证书的实体的公钥以及实体的一些信息。这些数据都将会成为证书的一部分。一个CSR总是用它所携带的公钥所对应私钥进行加密。

CSR创建通常是一个交互过程，你会需要提供能区别证书名称的元素。仔细阅读一下openssl提供的指南，如果要留空某一个字段，最好输入点号（.)而不是直接回车。因为直接回车的话，openssl会把这个字段用默认值填充，而不是空。（这个行为在使用默认配置的openssl时没有意义，但如果你修改了openssl的默认配置时，就要小心了）

$ openssl req -new -key fd.key -out fd.csr

CSR创建之后，可以用来签署你自己的证书，或者发送给公共证书认证机构签署证书。下面描述的就是这两种方案。在开始之前，再检查一下CSR是正确的：

$ openssl req -text -in fd.csr -noout Certificate Request: Data: Version: 0 (0x0) Subject: C=GB, L=London, O=Feisty Duck Ltd, CN=www.feistyduck.com/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b7:fc:ca:1c:a6:c8:56:bb:a3:26:d1:df:e4:e3: [16 more lines...] d1:57 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha1WithRSAEncryption a7:43:56:b2:cf:ed:c7:24:3e:36:0f:6b:88:e9:49:03:a6:91: [13 more lines...] 47:8b:e3:28

无人值守的CSR创建

可以通过使用一个配置文件，使得csr的创建过程自动化，并且做一个无法交互的配置。

一个配置文件的例子如下（fd.cnf）：

`[req] prompt = no distinguished_name = dn req_extensions = ext input_password = PASSPHRASE

[dn] CN = www.feistyduck.com emailAddress = [email protected] O = Feisty Duck Ltd L = London C = GB

[ext] subjectAltName = DNS:www.feistyduck.com,DNS:feistyduck.com`

现在，使用以下命令，自动化CSR创建：

$ openssl req -new -config fd.cnf -key fd.key -out fd.csr

从现有证书创建CSR

如果你要续期一个证书，并不需要改变证书里的内容，那么用这个办法可以节省时间。使用一下命令，可以从现有证书中创建一个全新的CSR

$ openssl x509 -x509toreq -in fd.crt -out fd.csr -signkey fd.key

签署自有证书

如果你只是搭建一个自己使用的TLS服务器，你可能并不需要一个证书机构来给你签署一个可信任的证书。自己签署证书非常简单。最快的办法的就是生成一个自签名的证书。如果你使用firefox，第一次访问站点的时候你可以创建一个证书例外，之后访问站点就像一个公共授信站点一样的安全。

生成自签名证书的命令如下：

$ openssl x509 -req -days 365 -in fd.csr -signkey fd.key -out fd.crt Signature ok subject=/CN=www.feistyduck.com/[email protected]/O=Feisty Duck Ltd↩ /L=London/C=GB Getting Private key Enter pass phrase for fd.key: ****************

只要有密钥，其实你还可以一步就创建自有签名证书，而不需要先创建csr：

$ openssl req -new -x509 -days 365 -key fd.key -out fd.crt

如果你不想被问问题，使用-subj开关提供认证信息：

$ openssl req -new -x509 -days 365 -key fd.key -out fd.crt \ -subj "/C=GB/L=London/O=Feisty Duck Ltd/CN=www.feistyduck.com"

创建多域名共用证书

By default, certificates produced by OpenSSL have only one common name and are valid for only one hostname. Because of this, even if you have related web sites, you are forced to use a separate certificate for each site. In this situation, using a single multidomain certificate makes much more sense. Further, even when you’re running a single web site, you need to ensure that the certificate is valid for all possible paths that end users can take to reach it. In practice, this means using at least two names, one with the www prefix and one without (e.g., www.feistyduck.com and feistyduck.com).

There are two mechanisms for supporting multiple hostnames in a certificate. The first is to list all desired hostnames using an X.509 extension called Subject Alternative Name (SAN). The second is to use wildcards. You can also use a combination of the two approaches when it’s more convenient. In practice, for most sites, you can specify a bare domain name and a wildcard to cover all the subdomains (e.g., feistyduck.com and *.feistyduck.com).

Warning When a certificate contains alternative names, all common names are ignored. Newer certificates produced by CAs may not even include any common names. For that reason, include all desired hostnames on the alternative names list.

First, place the extension information in a separate text file. I’m going to call it fd.ext. In the file, specify the name of the extension (subjectAltName) and list the desired hostnames, as in the following example:

subjectAltName = DNS:*.feistyduck.com, DNS:feistyduck.com Then, when using the x509 command to issue a certificate, refer to the file using the -extfile switch:

$ openssl x509 -req -days 365 \ -in fd.csr -signkey fd.key -out fd.crt \ -extfile fd.ext The rest of the process is no different from before. But when you examine the generated certificate afterward, you’ll find that it contains the SAN extension:

X509v3 extensions: X509v3 Subject Alternative Name: DNS:*.feistyduck.com, DNS:feistyduck.com

检查证书

$ openssl x509 -text -in fd.crt -noout

自签名证书通常包含最基本的认证数据。由公共认证机构签发的证书包含更多信息：

基础约束扩展(Basic Constraints extension)

BC用来标记证书属于某个CA， 赋予证书签署其他证书的能力。非CA证书要么省略该扩展，要么把CA值设为FALSE。 这个扩展非常关键，所有能被软件使用的证书必须能理解它。

密钥使用范围(Key Usage, KU)和扩展密钥使用范围(Extended Key Usage, EKU)

限制证书的使用范围。如果该信息存在，则只有它列出的使用范围是被允许的，没有该信息表示该证书使用不受限。

CRL Distribution Points extension

the CRL Distribution Points extension lists the addresses where the CA’s Certificate Revocation List (CRL) information can be found. This information is important in cases in which certificates need to be revoked. CRLs are CA-signed lists of revoked certificates, published at regular time intervals (e.g., seven days).

Certificate Policies extension

used to indicate the policy under which the certificate was issued. For example, this is where extended validation (EV) indicators can be found (as in the example that follows). The indicators are in the form of unique object identifiers (OIDs), and they are unique to the issuing CA. In addition, this extension often contains one or more Certificate Policy Statement (CPS) points, which are usually web pages or PDF documents.

Authority Information Access (AIA) extension

contains two important pieces of information. First, it lists the address of the CA’s Online Certificate Status Protocol (OCSP) responder, which can be used to check for certificate revocation in real time. The extension may also contain a link to where the issuer’s certificate (the next certificate in the chain) can be found. These days, server certificates are rarely signed directly by trusted root certificates, which means that users must include one or more intermediate certificates in their configuration. Mistakes are easy to make and will invalidate the certificates. Some clients (e.g., Internet Explorer) will use the information provided in this extension to fix an incomplete certificate chain, but many clients won’t.

Subject Key Identifier and Authority Key Identifier extensions

establish unique subject and authority key identifiers, respectively. The value specified in the Authority Key Identifier extension of a certificate must match the value specified in the Subject Key Identifier extension in the issuing certificate. This information is very useful during the certification path-building process, in which a client is trying to find all possible paths from a leaf (server) certificate to a trusted root. Certification authorities will often use one private key with more than one certificate, and this field allows software to reliably identify which certificate can be matched to which key. In the real world, many certificate chains supplied by servers are invalid, but that fact often goes unnoticed because browsers are able to find alternative trust paths.

Subject Alternative Name extension

used to list all the hostnames for which the certificate is valid. This extension used to be optional; if it isn’t present, clients fall back to using the information provided in the Common Name (CN), which is part of the Subject field. If the extension is present, then the content of the CN field is ignored during validation.