3

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?

Improve this question

3 Answers 3

Reset to default
1

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/

Improve this answer
3
1

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.

Improve this answer
5
  • 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, 2009 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, 2009 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, 2009 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, 2009 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, 2009 at 19:28
0

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.

Improve this answer
1
  • 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, 2009 at 17:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .