[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnutls fails to use Verisign CA cert without a Basic Constraint

From: Douglas E. Engert
Subject: Re: gnutls fails to use Verisign CA cert without a Basic Constraint
Date: Mon, 12 Jan 2009 10:00:08 -0600
User-agent: Thunderbird (Windows/20081209)

For all the reasons sighted, I agree that V1 certs should not be trusted,
and in our case its a Verisign cert used to sign intermediate certs.
The current code also needs to be fixed, but
stopping at the first trusted cert in the chain might be the best solution
(for us at least) and then get Ubuntu to backport that change, rather
then having to get them to modify OpenLDAP and potentially opening up the
V1 hole you are trying to close.

A goal is to use the vendor's (Ubuntu) code if at all possible as we run
this on many production machines.

Simon Josefsson wrote:
Nikos Mavrogiannopoulos <address@hidden> writes:

On Sat, 10 Jan 2009 13:05:05 +0100

Nikos, what do you think?  You wrote the code here, and introduced the
work-around flags to deal with V1 certs.
X.509 v1 certificates are quite dangerous to use and should be avoided
because of the inherited issues with them (a V1 CA certificate cannot be
distinguished from a V1 server certificate or a V1 person certificate,
thus if one has a V1 server certificate in his trusted certificate list
wouldn't want to trust it as a CA as well).

For these reasons V1, certificates are not trusted to be signers by
default unless the following two flags are set:


This one allows a v1 certificate from the trusted list to be valid as
a CA (here one must know that he should not add V1 server certificates
in his trusted list).


This one is quite dangerous. It allows any intermediate V1 certificate
to be used as a signer. This means that if I manage to get a CA to give
me a V1 personal certificate, I can act as a CA if this flag is set.

Good points.

For things that aren't documented, I think we can be pragmatic and
come up with quick fixes and apply them to the v2.6.x branch as
needed.  But anything that changes documented and intended behaviour
is not appropriate for our stable branch IMHO.
I didn't follow the issue closely, but I'd be against any change of the
V1 certificate handling unless there is a good reason to do so. V1
certificates should not be used any more.

I agree fully.

I believe the proper fix in this situation is to patch GnuTLS as
suggested, and fix the applications to use the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter when verifying chains using
GnuTLS.  Douglas, if you can confirm that this solves your problem, we
can release a new stable 2.6.x with the fix relatively quickly.

If the code change on you TODO list to stop when an intermediate CA
cert is found on the trusted CA list, then this would solve my
problem, as the intermediate cert is V3 and has CA:TRUE, and is
Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
which we could release as the next stable branch relatively quickly.
About releasing 2.7, I think we should wait for the TLS 1.2 support to
be completed or remove it from the supported list.

I agree.



 Douglas E. Engert  <address@hidden>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444

reply via email to

[Prev in Thread] Current Thread [Next in Thread]