Someone brought to my attention today that Go Daddy is now offering a
"6-in-1" SSL certificate where they allow you to associate multiple
domain names from different TLDs with a single certificate:
%2B&app%5Fhdr=&ci=4635#anchor76
(For example, you might have an SSL certificate specifying the domain
names as "foo.com", "foo.net", "foo.org", and so on, up to six total.)
Based on my reading of RFC 2818 (in particular section 3.1) and what I
think is the relevant source code (in the NSS function
cert_VerifySubjectAltName) it appears that such certificates should work
fine in Firefox and other Mozilla-based products, assuming that the
names are stored in the certificate using SubjectAltName as opposed to
CN. Am I correct in this supposition?
Frank

Frank Hecker wrote:
Someone brought to my attention today that Go Daddy is now offering a
"6-in-1" SSL certificate where they allow you to associate multiple
domain names from different TLDs with a single certificate:

%2B&app%5Fhdr=&ci=4635#anchor76

(For example, you might have an SSL certificate specifying the domain
names as "foo.com", "foo.net", "foo.org", and so on, up to six total.)

Based on my reading of RFC 2818 (in particular section 3.1) and what I
think is the relevant source code (in the NSS function
cert_VerifySubjectAltName) it appears that such certificates should work
fine in Firefox and other Mozilla-based products, assuming that the
names are stored in the certificate using SubjectAltName as opposed to
CN. Am I correct in this supposition?

Yes. It should.
I'd like to see an actual example of their 6-in-1 or "wildcard" certs
in use on the internet.

Nelson B wrote:
I'd like to see an actual example of their 6-in-1 or "wildcard" certs
in use on the internet.

Thanks for confirming my guess. Unfortunately I haven't seen any "live"
examples of Go Daddy "6-in-1" certificates. You'd think that Go Daddy
would have helpfully provided an example site for prospective buyers,
but apparently not. (To the contrary, Go Daddy doesn't even seem to be
using this yet on their own sites; for a bit of amusement try going to
<https://www.godaddy.net/:-)

Go Daddy does have a FAQ that answers some more questions about the
6-in-1 certificates:

Note that they are restricting this specifically to the case where you
have different TLD variants, e.g., foo.com, foo.org, foo.net, and so on.
Like the restriction to six domains total, I presume that this
restriction was done for marketing reasons, as it appears to me that the
underlying implementation in NSS (and presumably in IE and other
browsers) would actually permit multiple unrelated domain names to be
used, e.g., foo.com, bar.net, baz.org, etc.

The more general capability would seem to be useful for the following
cases where you have multiple domains all resolving to a single IP
address (and hence a single web server instance):

* Supporting redirection of commonly misspelled domains back to the
canonical domain, e.g., <https://www.exampel.com/to
<https://www.example.com/>.

* Supporting redirection of country-specific domain names back to a
single global domain, e.g., <https://www.example.co.uk/to
<https://www.example.com/>.

There's also the very common case of supporting both plain example.com
vs. www.example.com; I can't remember whether this can be handled using
wildcarding or would need both domain names in the certificate.

In any case I'm surprised that more commercial CAs aren't supporting the
issuance of SSL certificates that handle some of these common situations.

Frank

Jean-Marc Desperrier wrote:
Frank Hecker wrote:
>In any case I'm surprised that more commercial CAs aren't supporting
>the issuance of SSL certificates that handle some of these common
>situations.

Selling one cert per domain is simpler to support

Simpler for the CA, but not (I'd argue) for the customer. I'd rather
install one certificate than try to figure out how to (for example) set
up separate SSL certificates for "hecker.org" vs. "www.hecker.org" for a
server on a single IP address.

*and* brings more money.

Perhaps, but I think this can be argued both ways. For example,
currently my CA is making $X/year from me for my single
"www.hecker.org". I'd gladly pay 25-50% more for the ability to have
"hecker.org" on that cert as well, but to my knowledge CAs don't offer
that choice and are therefore missing out on that extra revenue.

They would be more interested in making a reduced price when
someone buys a bunch of cert with the same domain under various DNS than
supporting that.

Certainly allowing arbitrary sets of domain names in certs is a
potential problem for CAs, since (for example) someone with five
different servers could get a single cert with the five domain names and
then share certs and private keys among the servers. However I can't
help but think that a creative CA could figure out ways to address this
problem (if it really would be a problem).

Frank

Gervase Markham wrote:
Frank Hecker wrote:
>In any case I'm surprised that more commercial CAs aren't supporting the
>issuance of SSL certificates that handle some of these common situations.

This may be partly because it's only recently that people figured out a
compatible way through the maze of ten different possible ways to do
this.

Gerv, I am quite surprised to see this criticism, coming from you

AFAIK, there's *NE* way, well defined in standard RFC 3280 in 4/2002,
to support multiple DNS names in a certificate. It's THE standard way.
It's supported by all the major browser productsnow , and has been for
at least 4 years.

I seem to remember CACert.org's wiki having a page on it; they
took months trying different options before settling on one that worked

That can happen when one chooses trial-and-error (as opposed to reading the
standard RFC) as a means to find what works.

Being a "certification authority" necessitates being expert in the standards
on certificates (among other things). I should think that wannabe CAs
would not wish to publicly demonstrate their ignorance of the standards.

In any case, I should not interpret an individual CA's difficulty in
finding the standard method as a flaw in the standard or as a flaw in any
browser's implementation of it.

Frank Hecker wrote:
Someone brought to my attention today that Go Daddy is now offering a
"6-in-1" SSL certificate where they allow you to associate multiple
domain names from different TLDs with a single certificate:

%2B&app%5Fhdr=&ci=4635#anchor76

In looking at Geotrust's request to add more root CA certs (bug 294916)
I happened to notice that Geotrust offers a somewhat similar service,
Power Server ID:

Unlike the Go Daddy offering, it appears to be oriented toward people
who run multiple subdomains under a single overall domain (e.g.,
"www.example.com", "foo.example.com", and "bar.baz.example.com" under
"example.com"). From the product description it appears that one domain
goes in the CN attribute and the rest in SubjectAltName.

Frank

Frank Hecker wrote:

In looking at Geotrust's request to add more root CA certs (bug 294916)
I happened to notice that Geotrust offers a somewhat similar service,
[snip]
From the product description it appears that one domain
goes in the CN attribute and the rest in SubjectAltName.

That's not conformant with the relevant RFC. RFC 2818 says:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. , 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.

It's either one or the other, not the union of the two. Conformant clients
will not recognize the name in the subject common name when the subject
alt name is present.

Subject alt name can have many names. Subject common name can have only one.
Subject Alt Name is the standard. Subject Common Name, the old defacto
standard, is now deprecated. There's no reason not to include ALL the
relevant names in the subject alt name.

I think we need to be clear that, to be admitted to mozilla's CA list,
CAs must be conforming with the relevant RFCs.

Chris,

Below is comment from Nelson Bolyard of the NSS team regarding
Geotrust's Power Server ID certificates. Could you clarify how Geotrust
is implementing these certificates (i.e., in terms of using CN vs.
SubjectAltName)? You may in fact be doing the conformant thing, and I've
misinterpreted the description at

Thanks in advance for any info you can provide on this.

Frank

Nelson B wrote:
Frank Hecker wrote:

>In looking at Geotrust's request to add more root CA certs (bug 294916)
>I happened to notice that Geotrust offers a somewhat similar service,
>[snip]
>From the product description it appears that one domain
>goes in the CN attribute and the rest in SubjectAltName.

That's not conformant with the relevant RFC. RFC 2818 says:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. , 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.

It's either one or the other, not the union of the two. Conformant clients
will not recognize the name in the subject common name when the subject
alt name is present.

Subject alt name can have many names. Subject common name can have only one.
Subject Alt Name is the standard. Subject Common Name, the old defacto
standard, is now deprecated. There's no reason not to include ALL the
relevant names in the subject alt name.

I think we need to be clear that, to be admitted to mozilla's CA list,
CAs must be conforming with the relevant RFCs.

Nelson B wrote:
Frank Hecker wrote:

>In looking at Geotrust's request to add more root CA certs (bug 294916)
>I happened to notice that Geotrust offers a somewhat similar service,
>[snip]
>From the product description it appears that one domain
>goes in the CN attribute and the rest in SubjectAltName.

That's not conformant with the relevant RFC.

Thanks for the reply. I'll forward your comments to Geotrust.

Frank

Frank Hecker wrote:
Nelson B wrote:
>Frank Hecker wrote:
>>
In looking at Geotrust's request to add more root CA certs (bug
294916) I happened to notice that Geotrust offers a somewhat similar
service, [snip]
From the product description it appears that one domain goes in the
CN attribute and the rest in SubjectAltName.
>>
>That's not conformant with the relevant RFC.

Thanks for the reply. I'll forward your comments to Geotrust.

, and I should add that what I wrote was a guess based on the product
description on Geotrust's web site; I've never seen an actual example of
these certificates, so I could well be wrong.

Frank

I think that a part of Mozilla's acceptance policy should be the CA
providing copies of certificates for technical validation, as well as
the more political validation method which we've dealt with up to this
point.
-Kyle H

8/4/06, Frank Hecker <hecker (AT) mozillafoundation (DOT) orgwrote:
Frank Hecker wrote:
Nelson B wrote:
>Frank Hecker wrote:
>>
In looking at Geotrust's request to add more root CA certs (bug
294916) I happened to notice that Geotrust offers a somewhat similar
service, [snip]
From the product description it appears that one domain goes in the
CN attribute and the rest in SubjectAltName.
>>
>That's not conformant with the relevant RFC.
>
Thanks for the reply. I'll forward your comments to Geotrust.

, and I should add that what I wrote was a guess based on the product
description on Geotrust's web site; I've never seen an actual example of
these certificates, so I could well be wrong.

Frank

Frank Hecker wrote:
Nelson B wrote:
>Frank Hecker wrote:
>>
In looking at Geotrust's request to add more root CA certs (bug
294916) I happened to notice that Geotrust offers a somewhat similar
service, [snip]
From the product description it appears that one domain goes in the
CN attribute and the rest in SubjectAltName.
>>
>That's not conformant with the relevant RFC.

Thanks for the reply. I'll forward your comments to Geotrust.

I got a reply from Geotrust. The product description on their web site
is incorrect. All the domains go into SubjectAltName.

Frank