[gnutls-help] Change in staleness behaviour of gnutls_x509_crt_t values?

[Daniel Morrison]

 Hi!

I am new to gnutls so apologies if this is obvious but I've struggled to
determine this.

The company I work for makes use of gnutls in the following way:
1) initialise "gnutls_x509_crt_t" object using "gnutls_x509_cert_init"
2) populate various values using "gnutls_x509_crt_set_key",
"gnutls_x509_crt_set_dn_by_oid" etc. and sign it with
"gnutls_x509_crt_sign2", providing it with the issuing CA.
3) Provide the complete chain (including the issuing CA, in order) to the
"gnutls_certificate_set_x509_key" function.

Recently we upgraded from 3.3.26 to 3.6.7 (a big jump I realise!) and found
that the "gnutls_pcert_import_x509_list" call, inside
"gnutls_certificate_set_x509_key" is failing to determine that the first
certificate is issued by the 2nd cert in the chain. As such it fails to
import the rest of the chain during the sort process.

Debugging using gdb shows that various fields inside the
"gnutls_x509_crt_t" instance, such as "raw_dn" and "raw_issuer_dn" are
blank. Exporting the certificate into a raw char buffer via
"gnutls_x509_crt_export", and then back into a new "gnutls_x509_crt_t"
instance via "gnutls_x509_crt_import" then shows that these fields are
correctly populated and all works as expected.

Is this the correct expected behaviour (i.e. these fields remain stale
until exported/imported) and did this behaviour change at some point during
the last few years?

Thanks for any assistance.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20200821/a17847be/attachment.html>