gnutls fails to use Verisign CA cert without a Basic Constraint

[Douglas E. Engert]

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 <n.mavrogiannopoulos at gmail.com> 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:
>>
>> 1. GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>>
>> 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).
>>
>> 2. GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT
>>
>> 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
>>>> trusted.
>>> 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.
> 
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444