News

Welcome to End Point’s blog

OpenSSL CSR with Alternative Names one-line

20170216 - Edit - I changed this post to use a different method than what I used in the original version cause X509v3 extensions were not created or seen correctly by many certificate providers.

I find it hard to remember a period in my whole life in which I issued, reissued, renewed and revoked so many certificates.

And while that's usually fun and interesting, there's one thing I often needed and never figured out, till a few days ago, which is how to generate CSRs (Certificate Signing Requests) with AlternativeNames (eg: including www and non-www domain in the same cert) with a one-liner command.

This need is due to the fact that some certificate providers (like GeoTrust) don't cover the parent domain when requesting a new certificate (eg: CSR for www.endpoint.com won't cover endpoint.com), unless you specifically request so.

Luckily that's not the case with other Certificate products (like RapidSSL) which already offer this feature built-in.

This scenario is starting to be problematic more often since we're seeing a growing number of customers supporting sites with HTTPs connections covering both www and "non-www" subdomains for their site.

Luckily the solution is pretty simple and straight-forward and the only requirement is that you should type the CSR subject on the command line directly, basically without the use of the interactive question mechanism.

If you managed to understand how an SSL certificate works this shouldn't be a huge problem, anyway just as a recap here's the list of the meaning for the common Subject entries you'll need:

C => Country

ST => State

L => City

O => Organization

OU => Organization Unit

CN => Common Name (eg: the main domain the certificate should cover)

emailAddress => main administrative point of contact for the certificate

So by using the common syntax for OpenSSL subject written via command line you need to specify all of the above (the OU is optional) and add another section called subjectAltName=.>

By adding DNS.n (where n is a sequential number) entries under the "subjectAltName" field you'll be able to add as many additional "alternate names" as you want, even not related to the main domain.

Obviously the first-level parent domain will be covered by most SSL products, unless specified differently.

So here's an example to generate a CSR which will cover *.your-new-domain.com and your-new-domain.com, all in one command:

25 comments:

One thing I'm curious about: I believe the RFCs state that if you use a Subject Alternative Name, you should supply all names as SANs, and the CN can be ignored by clients. If I understand correctly, that means you should list e.g. www.endpoint.com as the CN, and both www.endpoint.com and bare endpoint.com as SANs.

As can be read here, it seems that "some browsers" (yes, IE) may refer to this RFC strictly enough that if they found a SAN field they won't consider the CN field and only use the domains found in the SANs.

While the original "older" RFC didn't specifically endorsed nor encouraged that behavior, with the new RFC there was more confusion on how to read that part so some browser went that way.

The final answer is: since it's never a problem to have one domain in both fields (CN *and* SAN) but it can be a problem to have the main domain only in the CN when using SANs, it's better to have all domains present in both fields.

Since the CN only supports one domain, it's common practice to put the main domain there, and then repeat it in the SAN field along with all the additional ones.

@sushil_rangari this post assumed readers to have a solid grasp of certificate creation/management basics. Before jumping on SANs you should probably practice more on basic certificates.Specifically all the parameters should be customized to your specific situation.

@sushil_rangari it seems that something could have been wrong in the command you used to generate the certificate. In order to be of any help I'd nee to see the steps you took to create the certificate. Please create a pastebin and I'll be happy to take a look and try to help.

Hi Sushil Rangari, That behavior you noticed is the same one the other reader noticed in saying that it's not "X509v3 compliant", specifically meaning that the SAN will be part of the subject field instead of having a dedicated field. As I anticipated, this is not an issue with most certificate provider out there (NameCheap, GeoTrust, GoDaddy) while it may be an issue if you're dealing with software or appliances which needs certificates to be strictly X509v3 compliant. In that case I suggest using the classical file-based SAN generation approach.

Hi, I was wondering how one could use this format and also use a challenge phrase. When I use the syntax given it does not prompt for any further information. Putting /challengePassword=.../ doesn't seem to work.

I just developed a web based tool that will generate this command for you and display the output. http://kernelmanic.com/certificate-request-generator-with-multiple-common-names-and-subject-alternative-names/

Thanks - this post is really helpful. I would say though that using "New York" as an example in the openssl command itself is very confusing - I can't tell the difference between the different fields. Perhaps it should be changed to something else?

Can I use under "alt_names" DNS names of different servers and different domains? for example:DNS.1 = server1.exampledomain.comDNS.2 = server2.exampledomain.atDNS.3 = server3.exampledomain.comDNS.4 = server4.exampledomain.at