

Trusted certificate authority Certigna leaks its private key - ghalfacree
http://www.thinq.co.uk/2011/6/9/certigna-publishes-ssl-private-key-mistake/

======
jvehent
This would actually be a problem.... if the private key was good for anything.
Certigna's response says it is not:

"Certigna has issued a response claiming that the file represented a 'test'
certificate that had long since expired. "The private key available on the
server corresponds to a test certificate used on our website certigna.fr," the
company claimed. "It is impossible to generate new valid user certificates
from this key. Moreover, it is encrypted and is an SSL certificate expired
since July 2010. This key does not affect our infrastructure security. The
Certigna SSL authority’s private key is stored in HSM (Hardware Security
Module) and hence can never be recovered. This useless file has been removed."

~~~
ordinary
Just some sensationalist reporting without proper fact-checking, then. Again.

~~~
JoeAltmaier
Somebody stole a key from a Certificate authority server? Sensationalist?
yeah, sounds pretty sensational.

"They only stole junk from my house. So Your stuff is safe, somehow"

Anyway, they Did fact-check - and the company didn't respond. So they reported
what appeared to be a significant breach. Then, when the company responded,
they reported that too. Which has a name, which is "Responsible Journalism"

~~~
jerf
Beware of metaphors when trying to understand computer issues. What happened
(assuming this is the truth) is that a useless key was left on a public server
in a public directory, and it could be downloaded by anybody, at which point
it is useless. There is no helpful physical analogue to this situation. Just
understand it as it is directly, it's not that complicated.

Your metaphor clouds the issue, it does not bring understanding. "Breaking in"
to a computer network doesn't give you access to a "whole house", and what
occurred wasn't a break in, there's no part of that metaphor that actually
helps you understand the situation.

At best this shows a bit of carelessness, but then, a useless, expired key
doesn't necessarily require much care in handling, either. The only damage
here is PR, if what the company says is true.

------
Robin_Message
That level of blurring is almost certainly insufficient to actually redact the
information, as discussed in <http://dheera.net/projects/blur.php> (discussed
here <http://news.ycombinator.com/item?id=1939607>)

~~~
verroq
I don't think so, it'd take way too long to dictionary attack/bruteforce the
missing 64 x 9 characters of the blurred image. Which gives 64 ^ (64 x 9)
combinations judging from the base64 encoding.

That is assuming you have the blurring algorithm and font perfect.

~~~
binarymax
No - we already know that the same blurring algorithm was used for all the
characters. The font can be found and matched quickly and you only need to
calibrate the blur for one character. The blurring algorithm will give you a
pixel perfect representation for character match so its more on the order of
64 * 600 (600 is the approx number of chars blurred). This could be cracked in
a day or less by someone motivated enough.

~~~
verroq
How do you know that blurring one character produces the same effect as
blurring two characters close together?

~~~
jrockway
You don't need to know this. You make an image of the text for every
combination possible, apply the blur algorithm, and see which one is a pixel-
perfect match for to the image on the web site.

Or rather, you don't do this, you write a program to do it :)

~~~
verroq
But you'll have to go through 64 ^ (64 x 9), combinations which will take
years which was what I said in the first post.

------
JoachimSchipper
Of course, "just revoke" doesn't actually work: serving a outdated certificate
revocation list, or preventing a connection to the OCSP ("is this cert
revoked?") server causes browsers to trust "revoked" certificates. Worse, lots
of software doesn't even bother to do this check. This is why the browsers
hardcoded a list of compromised certificates last time.

This is even worse, though, because a lot of "real" certificates depend on
this CA. Also, there are no logs to make a blacklist of "bad" certificates, so
you can't just revoke a handful...

~~~
zwp
"a lot of "real" certificates depend on this CA"

How many? did you estimate from sequential serial number allocation?

I am surprised (even if it turns out this is "just" an encrypted webserver
key) that they aren't using hardware keys: (a) it's their core business (b)
they appear competent (CTO posts to technical mailing lists) (c) they have a
/29 so aren't just a single IP on an inaccessible low-end VPS.

ssllabs.com gives them a C rating.

------
EwanToo
I don't think this leak has included their own certificate authority key to
allow you to generate your own key signed by the CA (which thinq claims), just
the private key for the website, but it's certainly embarrassing for them.

They seem to have modified all the files in the directory overnight, and
removed the offending www.certigna.fr files from <http://www.certigna.fr/crl/>
(unless the website has an archived directory that the thinq.co.uk writer was
looking at)

~~~
yuhong
Well, unfortunately there are also other .pem files in the list.

~~~
EwanToo
But that doesn't mean their CA trusted root key has been disclosed - sure, the
pem files could contain their trusted root key, but they normally wouldn't.

For example, the file named certigna.pem exists on most Linux machines, it's
the public key not the private one, look at the ca-certificates package on
debian.

------
certigna
You can find the Certigna's explanations at
<http://www.certigna.fr/archives/2984>

------
mpclark
Bad show, thinq, that I had to read right through this story to get to the bit
that says 'all of the forgoing is a crock of shit'.

------
mooism2
I'm not terribly familiar with private key formats, but it appears to be
encrypted (the `Proc-Type` and `DEK-Info` lines). Is the `localKeyID` the
password used to encrypt?

~~~
pagekalisedown
(1) Yes, the key is encrypted.

(2) This is not necessarily the private key used to sign other certificates.

(3) If they're lucky, this is a private key only used for their web server.
OR, this key is an intermediate key. In which case they can invalidate it,
create a new one, and reissue certificates for all the affected customers.

