0

We want to use a SAN SSL certificate for the following domains:

  • example.com (common name)
  • abc.example.com
  • def.example.com
  • www.abc.example.com
  • www.def.example.com

When creating the CSR for this certificate, do I have to enter all these hostnames (beside the Common Name) into the Subject Alternative Names section? Is it required? Or can I leave them empty and only fill out the Common Name?

How do these SAN entries eventually get into the SSL certificate? Is this through the CSR (if they've been provided) or can a certificate provider add them during the generation process, and thus the SANs are not required in the CSR?

  • I would check with your SSL provider. I've created CSRs will additional names in a long time ago but it was a PITA. My current provider allow me to type names in when I place the order and I think that's fairly common these days – USD Matt Jun 6 '18 at 9:19
  • Some SSL vendors will assume that if you control example.com you control *.example.com. Some do not assume this. However, you will still need to enter each domain name either into the CSR or into the SSL vendor form (depends on the CA). You will also have to be able to validate the required domain names usually via an HTTP file or DNS TXT record. – John Hanley Jun 11 '18 at 2:46
0

Yes, you need to include each of the subject alternate names and the subject/common name in the Subject Alternate Names section of the CSR. Some certificate authorities will allow you to update a certificate to add new SANs to it, but this always requires an updated CSR.

DigiCert is a fantastic CA to use, and here are their instructions for adding a SAN to a certificate.

To add SANs to a certificate, you must generate a new CSR on your server, and then submit the CSR in your account. If you need instructions for creating the CSR, see our Create a CSR (Certificate Signing Request) page.

The full instructions are here: https://www.digicert.com/multi-domain-add-subject-alternative-names.htm.

How you create your initial CSR will vary depending on what platform you are creating and using the certificate on.

0

subjectAltName is required, from RFC 2818

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.

Your certificate authority can use the names in the request, or take other inputs such as via a form. Let's Encrypt is an example that fully automates the request and issue of subjectAltNames or wildcards according to the options you pass to your ACME script.

About wildcards, you get one '*' you can use in the leftmost label, per the rules in RFC 6125 6.4.3. That is very powerful, you can use one cert for everything. However, if compromised, the attacker has a valid cert for any name matching that pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.