[gnutls-devel] GnuTLS | Getting actual certificate path to a trusted CA (#1012)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Sun Sep 27 16:29:01 CEST 2020




Daiki Ueno commented:


@sahprasa @codesquid let me clarify the scope of this bug.

> The output of certtool unfortunately is not very helpful either when given the certificates sent by this server:

I think this is simply a leftover bug of (!1271), which should be fixed with !1338: the issuer of the second cert should be "COMODO RSA Certification Authority" instead of "AddTrust External CA Root". Other than that, I don't see anything wrong in the output.

As noted in https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352394245, GnuTLS can only process "linear" certificate chains. Therefore we don't need to care about the cases like the peer sends multiple intermediate CAs for the same subject. The replaced certificate is only at the root of the trust.

> I suggest adding a function that returns the full path to the trusted root as was used in gnutls_certificate_verify_peers.

Yes, this is the actual request; that is, the TLS applications should have a way to pass the `gnutls_verify_output_function` as a callback. I think the best way to do that is adding a function, say:
```c
void gnutls_session_set_verify_output_function(gnutls_session_t session,
                                               gnutls_verify_output_function *func);
```

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1012#note_419258883
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200927/932c9d17/attachment.html>


More information about the Gnutls-devel mailing list