Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

First off, this isn't a question about sub-domains or host headers and SSL.

What I want to know is can I build a certificate request or find a certificate provider that will issue a certificate with multiple CNs (Common Names) such that secure access to https://www.abcde.com -or- https://www.qwert.com doesn't appear to the browser to be mismatched to the CN in the SSL certificate?

BACKGROUND

We have a e-commerce application that runs a under the URL http://www.abcde.com. The application also has a secured portion, accessed as https://www.abcde.com. This is a very normal setup, with the exception of using a SSL wildcard certificate (*.abcde.com) because the sub-domain may vary depending on business use of this app. This sub-domain/domain name variance of the application has to do with customizing it's look-and-feel and transaction-cut percentage for selected partners of ours.

We now have a desired business use of the exact same application where by it would be accessed via the URL http://www.qwert.com, and of course, have a secure portion accessed as https://www.qwert.com.

This poses a problem because my certificate has been issued for *.abcde.com. According to Ken Schaefer, it's possible to generate a CSR with multiple CNs.

Have you heard of multiple CNs in a cert? Do you know how to create a CSR for this? And will any certificate vendor fulfill a request like this?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

You should check out something called Unified Communications Certificates.

Looking here may help you start down the road you want to go: http://rrr.thetruth.de/2008/04/openssl-certificates-with-multiple-domains-common-names/

share|improve this answer
    
This is really interesting. I wonder how straightforward this is on Windows? –  Clint Miller Aug 17 '09 at 17:44
1  
Also, here seems to be a site that provides affordable SSL certs with UCC: digicert.com/unified-communications-ssl-tls.htm and sslshopper.com/unified-communications-uc-ssl-certificates.html tell me if that's what you want. –  IceMage Aug 17 '09 at 18:27
    
This is currently the most promising option. It's unfortunate I have to loose the wildcard capabilities since I really want this for specifying a completely different top-level domain, but it may be the best we can do for now! Thanks for the links! –  Clint Miller Aug 17 '09 at 18:38

Ultimately, it is up to the policy of the CA to decide which fields to consume from your CSR. Many take the CN. Or one of them.

Usually, multiple domains are added to the same Certificate under subjectAlternativeName headers, not common name. CACert allows you to submit CSR's with many SAN's.

Why do others not? They want your money. So Microsoft and at least three CA's invented a new way to take your money by reusing exploiting existing technology with new rules. These are the UC Certificates linked to by IceMage.

share|improve this answer
    
That's right. And on top of that Wildcard Certificates only apply to subdomains, that is *.domain.tld, where as a UCC can apply across multiple sites. If you only have two sites, you might as well just get two different certificates, and host on two different IPs. –  IceMage Aug 17 '09 at 18:25
    
What's the status of CACert support in browsers (i.e., are the browser vendors shipping CACert's root certs in their cert bundle)? Besides CACert, I would be interested in finding anyone else. Heck, I'm even willing to pay. It's a trivial fee compared to the business it can enable through our application. –  Clint Miller Aug 17 '09 at 18:26
    
IceMage: The thing is, we are developing these partnership sites rather quickly- and more are in the plans, so I don't want to use up what few addresses are left in our IP space for this. And like I said, the different domains refer to the exact same application under the hood (with the dynamically-applied, partnership-specific changes). –  Clint Miller Aug 17 '09 at 18:28
    
If you are changing them regularly are you going to want to keep paying for new certificates all the time? –  JamesRyan Aug 17 '09 at 19:08
    
No, I'm not going to want to do that at all! That's the whole purpose of trying to find a way to do this by specifying multiple domain names in the SAN field in the cert. It looks like these UCC providers let you reissue certs as often as you want within the validity period. As best as I can tell, I don't give the CA a CSR with the SAN fields, but I specify it to them, via some web interface or otherwise, and they'll give me a new cert with those fields. –  Clint Miller Aug 17 '09 at 19:28

In a word, no...

As I was reading your question my initial thought was to "wildcard SSL certificates" but that's not what you're trying to do... you're trying to use MULTIPLE DOMAINS under the same SSL.

I currently don't know of any SSL issuer that does this type of thing. You might be able to get away with self-signed certs... but then your browser is going to start complaining... so that's no good.

I think your best/only real option here is to have a separate SSL certificate for every unique domain name but this poses another issue.

Every SSL certificate is going to require a separate IP address (assuming you want to run default port for these).

Depending on how many domains we're talking about... I think you have two options:

  1. Register a new SSL certificate for every different domain you want to support and configure your web server accordingly. (ie. virtual domains)

  2. Register a generic domain such as "secure-ssl-server.com" and buy a single wildcard certificate then name your sub-domains accordingly. (ie. abcde.secure-ssl-server.com, qwert.secure-ssl-server.com, wxyz.secure-ssl-server.com, etc.)

Personally, if you can get away with it, I'd be in favor of option #2 as its WAY easier to maintain a single wildcard cert than it is to mess around with lots of multiple certs.

Hope this helps.

share|improve this answer
    
Unfortunately, #2 isn't really an option as the specific business case is to have legitimate domain "aliases" for our site that are top-level domains and not sub-domains. Thanks for the input, though. –  Clint Miller Aug 17 '09 at 17:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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