[SSL Observatory] Duplicate private keys

[Andy Isaacson]

On Tue, Apr 05, 2011 at 12:19:29AM -0700, Andy Isaacson wrote:
> On Mon, Apr 04, 2011 at 11:35:55PM -0700, Chris Palmer wrote:
> > On Apr 4, 2011, at 7:02 PM, Andy Isaacson wrote:
> > 
> > > There are thousands of certs in the observatory with duplicate public
> > > exponent values but distinct, valid Subject strings.  The most
> 
> [as pointed out, I meant duplicate modulus.]
> 
> > > promiscuous public exponent is present in 780 distinct certificates (all
> > > with distinct CN= strings).  The ones I checked appear to be low-rent
> > > but legitimate commercial websites.  They're not all hosted on the same
> > > IP netblock or ISP.
> > 
> > Are these possibly also among the weak Debian keys? That might explain
> > the re-use.
> 
> No, the most frequent Debian bad key I could find only had 2 instances
> in valid_certs.

Looking into it a bit further...

Many of the duplicates are clearly multiple hosts within a single
organization.  Poor practice, certainly, but not as dramaticly bad as
the cross-org examples.

Many of the cross organizational examples I've seen are all signed by a
single CA.  For example a few dozen auto parts websites with the same
modulus, and X509 subject members:

OU=Hosted by Secure SSL Network, OU=Comodo InstantSSL

Others are almost certainly due to badly implemented software; there are
several hundred certs for the same modulus for a particular "secure
hosted webmail" product (all the domains point into the same netblock,
too, so perhaps this is another example of the "multiple hosts within a
single organization" anti-pattern.)

Some appear to be embedded products such as storage servers; in one case
at hand, the product appears to have generated 2200 distinct private
keys but also a heavy tail:

|         c | RSA Public Key:Modulus
|         3 | 00:da:c9:12...
|         3 | 00:b3:79:2f...
|         4 | 00:cb:50:1a...
|         5 | 00:e8:94:2f...
|         8 | 00:ad:c7:dc...
|         8 | 00:af:52:08...
|         8 | 00:b8:2e:c1...
|        11 | 00:b9:e1:fb...
|        18 | 00:ba:8e:e7...
|        28 | 00:ad:ab:f1...
|        31 | 00:9d:12:7b...
|        63 | 00:b6:6c:1c...

Perhaps due to a low entropy condition during first-boot key generation?

There are a few -- I've only seen two or three so far -- EV certs with
the same modulus as a non-EV cert.  I wonder if that's even explicitly
prohibited by the EV spec, I certainly never would have thought of such
a broken way to do it.

-andy