CNNIC cert signed by Entrust
Jan Schejbal
Given that I explicitly removed the trust bits on the CNNIC root cert,
I quite dislike the fact that Entrust basically just adds the trust
back in. Any explaination for why CNNIC has such a second cert, why
Entrust issues such Sub-CA certs, and why CNNIC has applied for adding
their own CA cert although they basically already were included via
Entrust? Is Entrust supposed to be doing such things?
Is there a way to disable the trust for that single CNNIC cert without
kicking out Entrust altogether? (Yes, I know that Entrust can and
probably will just sign another CNNIC cert once they want, so probably
I will kick them out, but I would like to have a "softer" option.) Are
many end-user certs on real-life websites depending on entrust, or can
I toss them out without missing too much?
Jan
Certification path for "CNNIC SSL"
Inhaber: C=CN,O=CNNIC SSL,CN=CNNIC SSL
Aussteller: C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref.
(limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure
Server Certification Authority
Validit�t: from 11.05.2007 14:03:22 UTC to 01.03.2012 05:00:00 UTC
-----BEGIN CERTIFICATE-----
MIIEFzCCA4CgAwIBAgIEQoeioDANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u
ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc
KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u
ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzA1
MTExNDAzMjJaFw0xMjAzMDEwNTAwMDBaMDUxCzAJBgNVBAYTAkNOMRIwEAYDVQQK
EwlDTk5JQyBTU0wxEjAQBgNVBAMTCUNOTklDIFNTTDCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAJi/7qMONmdodRqKb5QMZM8XaQLXy26EjTnBblL+WC1y
PGXxTFyYSjrJKB3iUKP1Inj9dymNfQqD0F0p/aWh6RClHb/NoAwR2zjIf8xrStVO
eUCieuDz5l7TVKZ/aklW/UcIzImj9SjRzixzJ0Qdd7L0SW11WgzUd/IEqHHy2DHq
3qJC3qUnfkWLmmPlE7QUJ4cg62kFwZ2vznHb9tlwGEPd2ik4iACBUL8X17x4BV//
DeOl1z75DpDMLjmUTi/vwmsc/1Ko9ElwrfkjF4L7XY/hbQ/N/qmhMMn8OBiIwbTI
14oRS/8eiUqTe0L0KwrC+Yo96HBTBRObAZWgV/X0ZxkCAwEAAaOCAR8wggEbMA4G
A1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEBBCcw
JTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC5lbnRydXN0Lm5ldC9zZXJ2ZXIxLmNybDARBgNV
HSAECjAIMAYGBFUdIAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8G
A1UdIwQYMBaAFPAXYhNVPbP/CgBr+1CEl/PtYtAaMB0GA1UdDgQWBBRL1eFRFqKn
7aOlx+D/sYcYDsDj1TAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG
9w0BAQUFAAOBgQBE8Wd1YSChOVKq/nmol4vS1BFliayedJBiTW9EfeyCtfPvCb9m
RjpT2+k4P2y9xJSFOB7Z9FsvcjMwqUWdf9qDMWqm4QXddxlztDtZ6PZiSvZ3H+mX
iWa/mCLLmFhoTElB/XYY4aqg/smxWaVJzHcbcP0ED5PeCxQiFpgbHeRVig==
-----END CERTIFICATE-----
(entrust cert removed)
--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...
Stephen Schultze
> I just found a CNNIC cert in my cert store that was signed by entrust.
> Given that I explicitly removed the trust bits on the CNNIC root cert,
> I quite dislike the fact that Entrust basically just adds the trust
> back in.
There seems to be a real flaw in the claim that users have control
over their trusted CAs, doesn't there? I have discussed the issue,
using the cert you pointed out as an example, here:
> Any explaination for why CNNIC has such a second cert,
They apparently convinced Entrust to cross-sign their root in 2007
because they had not yet convinced all the major vendors to add it as
a default root at that time.
> why Entrust issues such Sub-CA certs,
Because they make money on the transaction.
> and why CNNIC has applied for adding
> their own CA cert although they basically already were included via
> Entrust?
Probably because they did not want to be liable for revocation by
Entrust.
>Is Entrust supposed to be doing such things?
According to Frank's interpretation of the current approval process,
CAs are supposed to disclose all "third-party public subordinate CAs":
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc
However, these requirements were adopted after the cert was approved
(without anybody participating in the public comment period) in 2007:
https://bugzilla.mozilla.org/show_bug.cgi?id=382352#c12
So, Entrust appears to not have technically violated any part of the
policy. Kathleen has noted that:
"We don't usually go back and retroactively apply root inclusion
process changes to roots. The exception being that we have started to
require regularly updated audit documents for all included root
certificate authorities."
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045#c9c1c678497fae86
There also appears to be some speculation that upon requiring updated
audit documents, Mozilla will also require an updated list of "third-
party public subordinate CAs", but I don't see evidence of this being
the case. Furthermore, it appears that Mozilla has not in fact
required Entrust to provide updated audit documents, given that the
documents linked both from the Root CA tracking document and
Entrust.net link to audits which have expired:
http://www.mozilla.org/projects/security/certs/included/#Entrust
http://www.entrust.net/
> Is there a way to disable the trust for that single CNNIC cert without
> kicking out Entrust altogether? (Yes, I know that Entrust can and
> probably will just sign another CNNIC cert once they want, so probably
> I will kick them out, but I would like to have a "softer" option.)
This problem goes far beyond Entrust. It is endemic to the Sub-CA
delegation system (and market) altogether. Many root CAs sell Sub-
CAs.
> Are
> many end-user certs on real-life websites depending on entrust, or can
> I toss them out without missing too much?
I believe that many are, and even more depend on other roots that also
sell Sub-CAs.
It's worth noting that you did precisely what Kathleen suggested in
order to un-trust CNNIC, but the technical and policy structures in
Mozilla's trust model mean that her suggestion does not account for
the loophole you observed:
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/17be3bd7e0b33e8c/17a6c1eb6b163425#8e916485c0280b60
Eddy Nigg
>> why Entrust issues such Sub-CA certs,
>>
> Because they make money on the transaction.
>
Actually one thing that gives me some confidence is, that Entrust DID
sign their CA root. I expect that should there be at any time a problem,
they'll revoke that signature. Of course there is a business interest,
but Entrust also try to take their primary business quite serious from
what I can see. And I hope this is the case also here :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Stephen Schultze
> On 05/25/2010 07:27 PM, From Stephen Schultze:
>
> >> why Entrust issues such Sub-CA certs,
>
> > Because they make money on the transaction.
>
> Actually one thing that gives me some confidence is, that Entrust DID
> sign their CA root. I expect that should there be at any time a problem,
> they'll revoke that signature.
But by that time the problem will have occurred (whatever that problem
may be).
And, in any event, that's not the problem Jan is describing. The
problem he's describing is that *he* doesn't trust CNNIC no matter
what Entrust thinks. Nevertheless, the system as it works today
effectively forces him to trust CNNIC.
Stephen Schultze
>
> >> why Entrust issues such Sub-CA certs,
>
> > Because they make money on the transaction.
>
> Actually one thing that gives me some confidence is, that Entrust DID
> sign their CA root. I expect that should there be at any time a problem,
> they'll revoke that signature.
But by that time the problem will have occurred (whatever that problem
Kathleen Wilson
> On May 25, 11:58 am, "Jan Schejbal"<jan.schejbal_n...@gmx.de> wrote:
> There also appears to be some speculation that upon requiring updated
> audit documents, Mozilla will also require an updated list of "third-
> party public subordinate CAs", but I don't see evidence of this being
> the case. Furthermore, it appears that Mozilla has not in fact
> required Entrust to provide updated audit documents, given that the
> documents linked both from the Root CA tracking document and
> Entrust.net link to audits which have expired:
>
> http://www.mozilla.org/projects/security/certs/included/#Entrust
> http://www.entrust.net/
>
Please note the text at the top of the page
http://www.mozilla.org/projects/security/certs/included/
"This is a list of companies and certificates included in the Mozilla
project Root CA store after March 1st, 2007. This list represents the
information that was considered when the CA applied for inclusion of
their root. This list also includes links to the original request. A
spreadsheet listing all root certificates and their most recent audit
statements can be found here."
And it includes a link to:
http://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
I have been using a spreadsheet in Google Docs to update CP/CPS links,
audits, contact information, and other information for every root
certificate included in NSS. I then publish portions of that spreadsheet
to the link above.
If you go to that link, you will see that for Entrust root certificates
there are indeed links to their audit that completed in February of this
year.
Kathleen
Nelson B
> On 5/26/10 9:35 PM, Nelson B wrote:
>> On 2010/05/25 10:20 PDT, Stephen Schultze wrote:
>>
>>> And, in any event, that's not the problem Jan is describing. The
>>> problem he's describing is that *he* doesn't trust CNNIC no matter
>>> what Entrust thinks. Nevertheless, the system as it works today
>>> effectively forces him to trust CNNIC.
>>
>> it should be, but it's quite possible to distrust it while trusting other
>> subordinate CAs issued by Entrust.
>
> As far as any real user is concerned, it's impossible. I believe you
> posted somewhere (I can't even find it at this moment) some kludge for
> generating a non-validating cert that you can stick in there instead of
> the actual one... but that is quite extreme.
That's not the method I would recommend for the average user. The method
for the average user requires no more than the check boxes found in FF's
cert manager UI.
> Even if that were trivially easy to do, it wouldn't solve the problem.
> The problem is that any of the dozens of CAs out there can create
> another cross-signed cert without the advance knowledge or subsequent
> notification of end users. That's what Jan experienced.
This says you're looking for a way to distrust all certs with a given
subject name, not only those issued by a certain issuer. That's worth some
thought.
Nelson B
> On 05/27/2010 05:12 AM, From Kurt Seifried:
>> and the apparent impossibility of kicking them out of the Mozilla root
>> store if they do misbehave
>
> Again, there must be a chance for corrective measures under normal and
> reasonable circumstances. Having said that, even removal of CA roots may
> happen (and some are indeed in the process of being removed).
>
>> (have any been removed for bad behavior ever?) is there is really any
>> behavior that will not be tolerated?
Didn't we pull the plug on a certain CA in Spain within the last 12 months?
Kurt Seifried
If memory serves ips asked to be removed
-Kurt
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Stephen Schultze
> On 2010/05/26 18:48 PDT, Steve Schultze wrote:
> > On 5/26/10 9:35 PM, Nelson B wrote:
> >> On 2010/05/25 10:20 PDT, Stephen Schultze wrote:
>
> >>> And, in any event, that's not the problem Jan is describing. The
> >>> problem he's describing is that *he* doesn't trust CNNIC no matter
> >>> what Entrust thinks. Nevertheless, the system as it works today
> >>> effectively forces him to trust CNNIC.
>
> >> I don't think so. It's not as easy to distrust that cross cert as I think
> >> it should be, but it's quite possible to distrust it while trusting other
> >> subordinate CAs issued by Entrust.
>
> > As far as any real user is concerned, it's impossible. I believe you
> > posted somewhere (I can't even find it at this moment) some kludge for
> > generating a non-validating cert that you can stick in there instead of
> > the actual one... but that is quite extreme.
>
> That's not the method I would recommend for the average user. The method
> for the average user requires no more than the check boxes found in FF's
> cert manager UI.
What's the method? You have explained here in the past that Sub-CAs
always inherit their trust from their parents:
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045#79efb08f1cb7651a
> > Even if that were trivially easy to do, it wouldn't solve the problem.
> > The problem is that any of the dozens of CAs out there can create
> > another cross-signed cert without the advance knowledge or subsequent
> > notification of end users. That's what Jan experienced.
>
> This says you're looking for a way to distrust all certs with a given
> subject name, not only those issued by a certain issuer. That's worth some
> thought.
But there's noting forcing a particular entity to use the same Subject
Name they have in the past, so that would be ineffective.
The real problem is that without full disclosure of the whole cert
hierarchy, there's no way for users to exercise control of their own
trust (except perhaps to untrust all root CAs).
Carl Wallace
Though it's not an answer to your question, at the NIST ID Trust
symposium a few months ago we demo'ed using trust anchor constraints
in Internet Explorer and Chrome. Details are here:
http://middleware.internet2.edu/idtrust/2010/papers/13-wallace-trust-anchor-management.pdf
http://middleware.internet2.edu/idtrust/2010/slides/13-wallace-trust-anchor-management.ppt
We used name constraints to exclude the CNNIC sub-CA while allowing
other certificates issued by Entrust to function.
Nelson Bolyard
> On May 28, 8:09 pm, Nelson B <nel...@bolyard.me> wrote:
>> That's not the method I would recommend for the average user. The method
>> for the average user requires no more than the check boxes found in FF's
>> cert manager UI.
>
> What's the method? You have explained here in the past that Sub-CAs
> always inherit their trust from their parents:
> http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045#79efb08f1cb7651a
When a cert has no trust bits of its own, it inherits trust from its parent.
If it's parent is a root and has no trust, then it inherits no trust.
While a root is trusted, Firefox routinely collects intermediate CA certs in
any chain that chains up to a trusted root. So, anyone who has used FF
for a while should have a significant set of certs issued by Entrust's root
in their cert store.
As I understand it, you want to continue to trust all but one of those
intermediate CA certs. So, what you do is:
- go into FF's cert manager authority tab.
- go find all the certs from Entrust
- "edit" the trust, setting explicit trust on any intermediates you want
to continue to trust.
- "edit the trust on Entrust's root, removing trust.
click. click. click. [...] done.
>>> Even if that were trivially easy to do, it wouldn't solve the problem.
>>> The problem is that any of the dozens of CAs out there can create
>>> another cross-signed cert without the advance knowledge or subsequent
>>> notification of end users. That's what Jan experienced.
>>
>> This says you're looking for a way to distrust all certs with a given
>> subject name, not only those issued by a certain issuer. That's worth some
>> thought.
>
> But there's noting forcing a particular entity to use the same Subject
> Name they have in the past, so that would be ineffective.
Sure there is: that name is found as the issuer name in ALL the certs
they've issued to date. To change that name, they have to reissue TONS of
certs, and then get the web site operators to replace the certs their
servers are sending out. <Astro> Rotsa Ruck! </Astro>
16+ years of SSL 3.x has shown that the single aspect of SSL web server
administration that is least well done, by FAR, is the installation and
replacement of intermediate CA certs. Any successful CA that contemplated
changing the name in their root cert is effectively starting over in the
market place. It won't happen
> The real problem is that without full disclosure of the whole cert
> hierarchy, there's no way for users to exercise control of their own
> trust (except perhaps to untrust all root CAs).
Yeah, users should trust their own guesses about whether any given server
cert is valid instead of trusting a CA. That's so much more reliable.
David E. Ross
> When a cert has no trust bits of its own, it inherits trust from its parent.
> If it's parent is a root and has no trust, then it inherits no trust.
> While a root is trusted, Firefox routinely collects intermediate CA certs in
> any chain that chains up to a trusted root. So, anyone who has used FF
> for a while should have a significant set of certs issued by Entrust's root
> in their cert store.
>
> As I understand it, you want to continue to trust all but one of those
> intermediate CA certs. So, what you do is:
> - go into FF's cert manager authority tab.
> - go find all the certs from Entrust
> - "edit" the trust, setting explicit trust on any intermediates you want
> to continue to trust.
> - "edit the trust on Entrust's root, removing trust.
>
> click. click. click. [...] done.
I'm using SeaMonkey, which should be using the same Certificate Manager
as Firefox. I don't see any intermediate certificates.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Eddy Nigg
> I'm using SeaMonkey, which should be using the same Certificate Manager
> as Firefox. I don't see any intermediate certificates.
>
They may be under different names and do not have to be under the
Entrust name. The description from Nelson is partly a bit misleading,
because any of the CA certificates marked as "Software Device" could be
signed by Entrust or by any of the other CAs for that matter.
Steve Schultze
> On 06/05/2010 06:07 PM, From David E. Ross:
>> I'm using SeaMonkey, which should be using the same Certificate Manager
>> as Firefox. I don't see any intermediate certificates.
>
> They may be under different names and do not have to be under the
> Entrust name. The description from Nelson is partly a bit misleading,
> because any of the CA certificates marked as "Software Device" could be
> signed by Entrust or by any of the other CAs for that matter.
Well, they should be listed "under" the Entrust roots (at least in the
Firefox CA browsing interface).
The bigger problem is that this assumes you have already collected any
intermediate certs you wish to to use. However, the intermediate certs
you wish to use may be unknown or not yet issued, so this solution
suffers from the same problem first observed (unknown Sub-CAs), but with
the opposite result (certs that the user would like to trust are not).
Jean-Marc Desperrier
> When a cert has no trust bits of its own, it inherits trust from its parent.
> If it's parent is a root and has no trust, then it inherits no trust.
> - go find all the certs from Entrust
> - "edit" the trust, setting explicit trust on any intermediates you want
> to continue to trust.
> - "edit the trust on Entrust's root, removing trust.
That's unfeasible. It needs to be made a tri-state : "trusted",
"unstrusted", "inherit".
It could be be adding a single supplementary boolean that says if the
other booleans have been set explicitly or not.
Nelson Bolyard
When a non-self-signed cert has no trust flags, it is in "inherit trust"
state.
When a self-signed cert has no trust flags, it is in "untrusted" state.
Nelson Bolyard
> On 6/5/10 11:26 AM, Eddy Nigg wrote:
>> On 06/05/2010 06:07 PM, From David E. Ross:
>>> I'm using SeaMonkey, which should be using the same Certificate Manager
>>> as Firefox. I don't see any intermediate certificates.
>> They may be under different names and do not have to be under the
>> Entrust name. The description from Nelson is partly a bit misleading,
>> because any of the CA certificates marked as "Software Device" could be
>> signed by Entrust or by any of the other CAs for that matter.
>
> Well, they should be listed "under" the Entrust roots (at least in the
> Firefox CA browsing interface).
Yes.
> The bigger problem is that this assumes you have already collected any
> intermediate certs you wish to to use. However, the intermediate certs
> you wish to use may be unknown or not yet issued, so this solution
> suffers from the same problem first observed (unknown Sub-CAs), but with
> the opposite result (certs that the user would like to trust are not).
Yes.
No doubt about it, the scheme I briefly described is not ideal by any
stretch of the imagination.
What you want is
https://bugzilla.mozilla.org/show_bug.cgi?id=470994
and maybe more.
Eddy Nigg
>> Well, they should be listed "under" the Entrust roots (at least in the
>> Firefox CA browsing interface).
>>
> Yes.
>
>
Well, I have an entry at the Authorities tab "Microsoft Internet
Authority" which is comprised only of "Software Security Device" with
three CA certificates. They chain to another root "GTE Cybertrust Global
Root" eventually and under that section are more Microsoft certificates.