Mailing List CGatePro@mail.stalker.com Message #105725
From: Terrence Koeman <terrence@darkness-reigns.com>
Subject: Expired, 1024bit, MD5 & a rogue/fake "Built-in trusted Certificate(s)" (root/CA certs) in CGP
Date: Tue, 21 Jul 2015 07:47:24 -0700
To: <CGatePro>
X-Mailer: Microsoft Outlook 15.0
Signed Data (Text SHA256)
Hi all,

My new GlobalSign Class 2 S/MIME certificate works fine with any mail client I have thrown it at, but results in a warning in red in the CGP webmail: "Content unaltered, signed by <empty> The presented certificate is issued by an unknown authority". Not surprisingly some local recipients don't trust my email (which is of course the exact opposite of what I want to accomplish with S/MIME).

I assumed that, since everyone's mail clients & operating systems have the CA my certificate depends on in their certificate store, CGP would also have it "Built-in". When I went poking around in the settings looking for the certificate store I found two lists of "Built-in and Trusted" certificates:

1. Settings -> Security
2. Users -> Domains -> [main domain]  -> Security -> Trusted (probably includes the former)

The documentation says about these lists: "There are several sets of the Trusted Certificates: Built-in trusted Certificates: these certificates are installed with the CommuniGate Pro Server software, and they are updated when the Server software is updated.".

The updating part doesn't seem to be happening (at least not on my installation). I upgraded to the latest CGP distribution (6.1.2), but a bunch of built-in certificates expired years ago, even a fake CA seems to be trusted and new CA root certificates haven't really been added the last few years (compared to major browsers, OSes and mail clients).

So too the CA certificate that my GlobalSign S/MIME certificate depends on. There are four built-in "GlobalSign" certificates:

GlobalSign
0400000000010F8626E60D - Expires: 15 Dec, 21

GlobalSign
040000000001100B8C9E8B - Expires: 28 Jan, 14 [EXPIRED]

GlobalSign Extended Validation CA
040000000001100B8CA11B - Expires: 15 Dec, 21

GlobalSign Root CA
040000000001154B5AC394 - Expires: 28 Jan, 28

But NOT the CA certificate my S/MIME signature depends on (which was published 6 years ago in 2009):

GlobalSign Root CA - Serial: 04000000000121585308A2
Can be found at https://secure.globalsign.net/cacert/Root-R3.crt

Of the expired certificates, there's one that expired in 2004, one in 2006, two in 2008, two in 2009, five in 2010, five in 2011, three in 2013, three in 2014 and two already in 2015. That's 24 expired certificates and no additions since 2011. Seeing as the major browsers and the windows CA store do not contain expired root CA certificates I'm thinking these should not be there.

So I have some questions about all this:

1. Is there something wrong with my CGP installation that causes the built-in list to not get updated or use some outdated source? Or is this really the list of certificates everyone running CGP trusts by default? I reinstalled CGP from the latest distribution on a clean system and it had the same list of built-in trusted root CAs, so I'm fearing it's the latter.

Obviously I could just add the missing root cert and my original problem would be fixed for users local to my server, but if the list is indeed outdated in all current CGP installations then this outdated list of root CA's could impact anyone using CGP, webmail & relying on S/MIME.

2. Does anyone know where Stalker's Root Certificate Policy is or whether they have one? Other companies maintaining a trusted CA list publish their policies of how they maintain their list. For instance:

Mozilla CA Certificate Policy
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Microsoft Root Certificate Program
http://social.technet.microsoft.com/wiki/contents/articles/3281.aspx

Apple Root Certificate Program
http://www.apple.com/certificateauthority/ca_program.html

This built-in list in CGP is providing the same functionality for its own webmail & S/MIME users as the lists provided with Windows, FireFox, Chrome, etc. do, so I'd have expected this list to be very well maintained, but that doesn't seem the case. One scary example I came across:

One CA in the list isn't even a REAL CA certificate: "MD5 Collisions Inc. (http://www.phreedom.org/md5)"- Serial 42

This "CA" is a proof-of-concept of an MD5 collission and allows a MITM if the clock is set before a certain date in 2004, see: http://www.phreedom.org/research/rogue-ca/ It is also added in FireFox, but in a "never-trust" context: https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/482751

3. That leads me to the next question: as far as I can tell from documentation this fake CA certificate is a "Built-in Trusted Certificate" to CGP and there is no "don't trust" bit in the case of CGP. So why was this CA added? Is its addition documented somewhere? If that fake CA is really trusted I'm going to have to doubt all built-in CAs.

4. Which then begs the question: how do I remove (some of) these Built-in CAs? I've looked, but I haven't seen a way to remove any either via the web interface or in a config file. I definitely do NOT trust any of these CAs:

a. MD5 Collisions Inc.'s rogue CA
b. TurkTrust (See: https://bugzilla.mozilla.org/show_bug.cgi?id=825022#c26)
c. TDC OCES CA (Should have been removed in 2013: https://bugzilla.mozilla.org/show_bug.cgi?id=847588)
d. AC Raíz Certicámara S.A. (Should have been removed in 2014: https://bugzilla.mozilla.org/show_bug.cgi?id=1013572)
e. Staat der Nederlanden Root CA (Diginotar, should have been removed in 2011: https://bugzilla.mozilla.org/show_bug.cgi?id=683449#c26 and https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates)
f. NetLock CA's (are MD5 certificates, see: https://bugzilla.mozilla.org/show_bug.cgi?id=682071)
g. Equifax and probably 10+ more (1024 bit key)
h. There's probably one or more CAs in there that sill use MD2 too :(

And for some reason some CA's are in the list twice.

5. So what's going on here, am I missing something? Is this actually a list of NON-trusted CAs somehow? Because that would make more sense; I simply can't imagine why the security of the webbased S/MIME would be completely gutted like this by default.

Anyway, thanks for reading & your opinion would be appreciated. I use S/MIME pretty heavily and this has me pretty worried.

--
Regards,
Terrence Koeman, MTh/BSc/BPsy

Darkness Reigns (Holding) B.V.
Please quote relevant replies in correspondence.


Content Unaltered as verified By:
Terrence Koeman <terrence@darkness-reigns.com>
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster