Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data

From: =JeffH <[email-masked]>
Date: Wed, 20 Oct 2010 09:01:32 -0700

>>ALL IN ONE services.acheckamerica.com suite.agile1.com www.etimeentry.com ALL
 >>IN ONE
 >
 > Duplicate instances of the same AVA at both ends of the DN (I'd like to see
 > that go in an LDAP directory!).
 >
 >>intranet.zsi.at bibliothek.intranet.zsi.at webmail.intranet.zsi.at
 >>wiki.intranet.zsi.at ztools.intranet.zsi.at
 >
 > This contains a DN with components thrown together in more or less arbitrary
 > order, again with CNs at both the start and end of the DN.
 >
 >>PACKAGING TAPE www.airmovers.com www.carpetextractors.com www.cleanfreak.com
 >>www.floorbuffers.com www.floorscrubbers.com www.packagingtapeinc.com
 >>www.ptipackaging.com PACKAGING TAPE
 >
 > Another double-ended DN with all sorts of bizarro (non-CN) components all over
 > it.
 >
<snip/>

Yes, those are "odd", and as previously noted, the strings you're quoting above 
are comprised of extracted & concatenated-with-space-separators CN values that 
Ivan "smooshed" all together into one column ("subjectCommonName") in his 
database table.

[If folks want to poke at the data themselves, request it from Ivan
http://www.ietf.org/mail-archive/web/certid/current/msg00484.html ]

fyi/fwiw, I count 946 certs in the dbase with more than one "CN" AVA in the 
subject DN, out of a total of 867361, so << 1%.

WRT "Duplicate instances of the same AVA at both ends of the DN...", perhaps 
RobS can provide some rationale for this practice?

Yes, they obviously aren't backing their CA databases with an X.500-based 
directory. I suspect hardly anyone (or even no-one) does so.

=JeffH

---

From: Rob Stradling <[email-masked]>
Date: Thu, 21 Oct 2010 12:33:38 +0100

On Wednesday 20 October 2010 17:01:32 =JeffH wrote:
> perhaps RobS can provide some rationale for this practice?

Hi Jeff.  Comments inline (taken from the message I sent you privately a few 
days ago)...

> > > ALL IN ONE services.acheckamerica.com suite.agile1.com
> > > www.etimeentry.com ALL IN ONE
> >
> > Duplicate instances of the same AVA at both ends of the DN (I'd like to
> > see that go in an LDAP directory!).
<snip>

"ORGANIZATIONNAME domain1 domain2 ... domainN ORGANIZATIONNAME"

I suspect that most (probably all) of these were issued by Comodo's CA system.  
Some years ago, when we first looked at the possibility of launching a "multi-
domain SSL certificate" product, our testing showed that some browsers would 
use multiple Common Names but not multiple SAN->dNSNames.  Of course, even 
back then the reverse was true with various other browsers.  To offer maximum 
compatibility, we elected to give certificate applicants the option of having 
all of their domains encoded as both CNs and dNSNames.
The Windows Certificate Viewer (for example) typically displays "Issued to: 
<Common Name>".  Since this only displays 1 CN, we figured it might confuse 
people when there were multiple CNs present in the certificate.  Therefore, we 
decided to (by default) encode the Organization Name as both the first and 
last CN, to make sure that the Windows Certificate Viewer would actually show 
"Issued to: <Organization Name encoded as a Common Name>".
Here's a (perhaps out-of-date) Wiki page from another CA who seem to have done 
pretty much the same research we did:
http://wiki.cacert.org/VhostTaskForce
Note that "CN+SubjectAltNames" has the most green "Yes"es.

> > This contains a DN with components thrown together in more or less
> > arbitrary order, again with CNs at both the start and end of the 

This was us too.  It's a variation on the previous case.  The customer elected 
to i) have the 2 Organization Name CNs omitted and ii) have a particular CN 
(intranet.zsi.at) first (i.e. encoded last) in the list.  (We normally encode 
them in alphabetical order).

> directory.

Indeed.

> I suspect hardly anyone (or even no-one) does so.
> 
> 
> =JeffH
> 
> _______________________________________________
> certid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/certid

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online