For an X.509 certificate to support multiple domains, it must use multiple Subject Alternative Name DNS entries, according to RFC 2818 (HTTP over TLS) (or RFC 6125):
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.)
As described in this document (except I would use -des3 too for the genrsa command, to protect the private key):
Make a copy your initial openssl.cnf file (the original is probably somewhere under /etc on Linux).
Edit it to add req_extensions = v3_req in the [ req ] section.
Edit it to add subjectAltName=DNS:www.example.com,DNS:www.other-example.com (one DNS: entry per host name you require) in the [ v3_req ] section.
Make OpenSSL use that configuration file. Call it with OPENSSL_CONF=/path/to/your/openssl.cnf openssl req ...
This being said, I wouldn't worry too much about setting any extension in the CSR. Any good CA should ignore whatever you've set in the CSR and only set whatever they have actually verified when issuing the actual certificate. They'll happily replace any RDN in your Subject DN (e.g. Country, Organization, ...) as well as any extension (SAN or Key Usage). Firstly, if they let any extension as requested in the CSR by the applicant, this would be a security risk, since some applicants could really get anything. Secondly, that's how they make extra money, by charging you for setting a few bits here and there (e.g. code signing extension): they'll make sure that you only get what you've paid for in your certificate. I understand, though, that you may want to put all the names you request in your CSR, just to be sure.
发布评论
评论（1）
对于支持多个域的 X.509 证书，它必须使用多个主题备用名称 DNS 条目，根据 RFC 2818（基于 TLS 的 HTTP）（或 RFC 6125）：
如本文档中所述（除了我会使用
-des3也适用于genrsa命令，以保护私钥）：openssl.cnf文件（原始文件可能是下面某处Linux 上的/etc）。[ req ]部分添加req_extensions = v3_req。[ v3_req ]部分。话虽这么说，我不会太担心在 CSR 中设置任何扩展名。任何好的 CA 都应该忽略您在 CSR 中设置的任何内容，而只设置他们在颁发实际证书时实际验证的内容。他们很乐意替换您的主题 DN 中的任何 RDN（例如国家/地区、组织……）以及任何扩展（SAN 或密钥用法）。首先，如果他们按照申请人在 CSR 中的要求允许任何延期，这将是一个安全风险，因为有些申请人真的可以得到任何东西。其次，这就是他们赚取额外收入的方式，通过向你收取一些设置的费用（例如代码签名扩展）：他们将确保你只得到你在证书中支付的费用。不过，我理解您可能希望将您请求的所有名称都放入 CSR 中，以确保万无一失。
For an X.509 certificate to support multiple domains, it must use multiple Subject Alternative Name DNS entries, according to RFC 2818 (HTTP over TLS) (or RFC 6125):
As described in this document (except I would use
-des3too for thegenrsacommand, to protect the private key):openssl.cnffile (the original is probably somewhere under/etcon Linux).req_extensions = v3_reqin the[ req ]section.subjectAltName=DNS:www.example.com,DNS:www.other-example.com(oneDNS:entry per host name you require) in the[ v3_req ]section.OPENSSL_CONF=/path/to/your/openssl.cnf openssl req ...This being said, I wouldn't worry too much about setting any extension in the CSR. Any good CA should ignore whatever you've set in the CSR and only set whatever they have actually verified when issuing the actual certificate. They'll happily replace any RDN in your Subject DN (e.g. Country, Organization, ...) as well as any extension (SAN or Key Usage). Firstly, if they let any extension as requested in the CSR by the applicant, this would be a security risk, since some applicants could really get anything. Secondly, that's how they make extra money, by charging you for setting a few bits here and there (e.g. code signing extension): they'll make sure that you only get what you've paid for in your certificate. I understand, though, that you may want to put all the names you request in your CSR, just to be sure.