[gnutls-dev] generate_rdn_seq() collects CA's issuers, why?

[Simon Josefsson]

Max Kellermann <max at duempel.org> writes:

> Hi,
>
> I'm currently hunting a tricky problem in my gnutls application; the
> client refuses to send any certificates to the server.  I tracked it
> all down to generate_rdn_seq(), which does not add the CA's DNs to the
> rdn_seq, but adds the CA's issuer's DNs.
>
> Why that?
>
> The CAs are being trusted, not the CA's issuers.  Now my client only
> sees the root CA, which did not sign his client certificate (Root CA
> -> client CA -> client certificate) - which is why the client will not
> send any certificate.
>
> Two experiments resulted in a success (which should not be):
>
> - first, I added another client certificate to the server's trusted
>   "CAs", now the client would see his own issuer in the list and sent
>   his own certificate
>
> - second, I modified generate_rdn_seq() to call
>   _gnutls_x509_crt_get_raw_dn() instead of
>   _gnutls_x509_crt_get_raw_issuer_dn() - the same: everything works
>   fine.
>
> If I'm correct and if this is really a bug in gnutls, I believe my
> second experiment is a solution for the gnutls bug.

Yup, I believe you are right.  RFC 4346 says:

      certificate_authorities
         A list of the distinguished names of acceptable certificate
         authorities.  These distinguished names may specify a desired
         distinguished name for a root CA or for a subordinate CA; thus,
         this message can be used to describe both known roots and a
         desired authorization space.  If the certificate_authorities
         list is empty then the client MAY send any certificate of the
         appropriate ClientCertificateType, unless there is some
         external arrangement to the contrary.

One reason this hasn't come up before may be that root CAs typically
have the same issuer and subject DN, and it is typical to trust root
CAs and not sub-ordinate CAs.

I have fixed this in CVS for both 1.6.x and 1.7.x.

Thanks,
Simon