Difference between revisions of "SSL/TLS certificate verification errors"

From Claws Mail FAQ
Jump to: navigation, search
('No certificate issuer found' during verification likely is caused by unreadable or misconfigured system certificate store.)
m
Line 2: Line 2:
  
  
Claws Mail uses gnutls or openssl libraries to deal with encryption (via libetpan dependency).
+
Claws Mail uses the gnutls library to deal with encryption.
  
Upon connection certificate from the server is always checked for validity. It entails
+
Upon connection the certificate from the server is always checked for validity. It entails
checking whole chain of certificates from CA root certificate, through any intermediate
+
checking the whole chain of certificates from the CA root certificate, any intermediate
certificate to the one presented by the mail server. For that chained verification to
+
certificates, to the certificate presented by the mail server. For that chained verification to
succeed ssl libraries must read root certificate from a local system store (file or dir).
+
succeed the gnutls library must read the root certificate from the local system (file or directory).
  
Location of this certificates store varies significantly from one distro to the other
+
The location of the certificates varies from one distro to the other
and if root CA certificate is unreadable by an user process (i.e. claws-mail) then verification fails with
+
and if the root CA certificate is unreadable by a user process (i.e. claws-mail) then verification fails with
cryptic error messages shown in 'Certificates change' dialog.
+
cryptic error messages shown in 'Certificates change' dialogue.
  
You may see either 'No certificate issuer found' then 'Signature: Uncheckable'.
+
You may see 'No certificate issuer found' then 'Signature: Uncheckable'.
  
It usually means that ssl library can not get CA root certificate from the store eg.
+
It usually means that gnutls library cannot read the CA root certificate,
because store is not readable. It happens that certificates upgrade package sets bad
+
because, e.g., it is not readable. It can happen that upgrade of a certificates package sets wrong
permissions on the store file or dir, so this is first check after seeing aforementioned
+
permissions on the file or directory, so that is the first thing to check after seeing such
errors. If the store is readable it MAY signal that you really got slapped with forged
+
errors. If the file/directory is readable it may be that that one of the intermediate certificates has expired,
certificate or someone allowed intermediate cert to expire.
+
or that that you really have received a forged certificate.
  
 
+
Listed below are the current (2018) locations of system certificates:
 
+
Below listed are current (2018) locations of system certificate stores:
+
  
 
<pre>
 
<pre>
 +
Debian: /etc/ssl/certs/ and /etc/ssl/certs/ca-certificates.crt
 
SUSE: /var/lib/ca-certificates/ca-bundle.pem (file)
 
SUSE: /var/lib/ca-certificates/ca-bundle.pem (file)
 
Debian: /etc/ssl/certs/ and /etc/ssl/certs/ca-certificates.crt
 
 
</pre>
 
</pre>
  
Historical known 'standardized' cert store locations:
+
Historical known 'standardized' certificate locations:
 
<pre>
 
<pre>
 
/usr/share/ssl/certs/
 
/usr/share/ssl/certs/

Revision as of 18:11, 29 March 2018

TL;DR 'No certificate issuer found' during verification likely is caused by unreadable or misconfigured system certificate store.


Claws Mail uses the gnutls library to deal with encryption.

Upon connection the certificate from the server is always checked for validity. It entails checking the whole chain of certificates from the CA root certificate, any intermediate certificates, to the certificate presented by the mail server. For that chained verification to succeed the gnutls library must read the root certificate from the local system (file or directory).

The location of the certificates varies from one distro to the other and if the root CA certificate is unreadable by a user process (i.e. claws-mail) then verification fails with cryptic error messages shown in 'Certificates change' dialogue.

You may see 'No certificate issuer found' then 'Signature: Uncheckable'.

It usually means that gnutls library cannot read the CA root certificate, because, e.g., it is not readable. It can happen that upgrade of a certificates package sets wrong permissions on the file or directory, so that is the first thing to check after seeing such errors. If the file/directory is readable it may be that that one of the intermediate certificates has expired, or that that you really have received a forged certificate.

Listed below are the current (2018) locations of system certificates:

Debian: /etc/ssl/certs/ and /etc/ssl/certs/ca-certificates.crt
SUSE: /var/lib/ca-certificates/ca-bundle.pem (file)

Historical known 'standardized' certificate locations:

/usr/share/ssl/certs/
/usr/share/ssl/
/usr/share/ssl/cert.pem (file)
/etc/ssl/certs/
/etc/ssl/certs/ca-bundle.crt (file)
/etc/ssl/certs/ca-certificates.crt (file)
/etc/pki/tls/certs/ca-bundle.crt (file)
/etc/pki/tls/certs/ca-bundle.trust.crt (file)
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/System/Library/OpenSSL/