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

[Development of GNU's TLS library]

Tim Kosse created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1012



## Description of the feature:

When looking at the fix for #1008 I realized that there does not appear to be a function to return the actual used certificate path to a trusted CA for a given session. The certificate path that eventually leads to a successful gnutls_certificate_verify_peers() may be different from the certificates sent by the server and subsequently returned by gnutls_certificate_get_peers(). Not only can the raw list be out of order, it may also contain CA certificates that aren't part of a path to a trusted root.

This is confusing when trying to understand why a particular certificate(-chain) is trusted, especially if there is something wrong with the CA certificates sent by the server, as is the case with e.g. support.sectigo.com sending expired CA certificates. The output of certtool unfortunately is not very helpful either when given the certificates sent by this server:
```
$ certtool --verify --infile support.sectigo.com.pem 
Note that no verification profile was selected. In the future the medium profile will be enabled by default.
Use --verify-profile low to apply the default verification of NORMAL priority string.
Loaded system trust (128 CAs available)
	Subject: CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Issuer: CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
	Checked against: CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
	Signature algorithm: RSA-SHA384
	Output: Not verified. The certificate is NOT trusted. The certificate chain uses expired certificate. 

	Subject: CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Issuer: CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
	Checked against: CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Signature algorithm: RSA-SHA384
	Output: Verified. The certificate is trusted. 

	Subject: CN=COMODO RSA Extended Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Issuer: CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Checked against: CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Signature algorithm: RSA-SHA384
	Output: Verified. The certificate is trusted. 

	Subject: CN=support.sectigo.com,OU=COMODO EV SSL,OU=IT,O=Comodo CA Limited,street=3rd Floor Building 26,street=Office Village Exchange Quay,street=Trafford Road,L=Salford,ST=Manchester,postalCode=M5 3EQ,C=GB,businessCategory=Private Organization,jurisdictionOfIncorporationCountryName=GB,serialNumber=04058690
	Issuer: CN=COMODO RSA Extended Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Checked against: CN=COMODO RSA Extended Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
	Signature algorithm: RSA-SHA256
	Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 
```
[support.sectigo.com.pem](/uploads/b39012da314113bb31b6980c072eca80/support.sectigo.com.pem)

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

## Applications that this feature may be relevant to:

Any programs that displays certificate paths, such as web browsers.

## Is this feature implemented in other libraries (and which)

I believe NSS implements this feature. Viewing the certificate path of support.sectigo.com in Firefox shows a path with a valid root CA, even though the server sends a chain with expired certificates.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1012
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/20200602/397bf932/attachment-0001.html>