Recently, several people noticed that GnuTLS behavior did not match its documentation with respect to two significant security concerns, both regarding X.509 certificate validation:

• Certificates with MD5 digests were considered acceptable for validation. They should not be, because of known weaknesses in that digest algorithm.
• Version 1 X.509 certificates were being accepted as Certificate Authorities if placed in the list of trusted certificates. It is impossible to distinguish between a V1 Authority certificate and a V1 End Entity certificate. This makes placement of such a cert in the trusted certificates list dangerously ambiguous, because you don't want holders of an end entity certificate to be able to act as certificate authorities)

GnuTLS has been fixed upstream, and a fix to at least the latter problem has already propagated into etch via a security upload. The lenny packages should already behave as documented (no MD5 digests accepted in cert validation, v1 certificates not explicitly acceptable as authorities).

However, this means that if you use GnuTLS-linked tools to connect to systems whose certificate chains rely on either MD5 digests (in anything but the root certificate) or on v1 certificates for any of the certificate authorities, your connections may fail due to this stricter validation.

There are already several bug reports about broken LDAP connections and broken mail connections due to these problems, and there have been reasonable concerns raised on debian-release about this.

So what can you do to make sure that the infrastructure you rely on or maintain does not depend on these outmoded and insecure features of X.509? Read on for concrete steps for administrators, developers/maintainers, and end users...

• If you are an administrator of a service that uses X.509 certificates:
  1. Check that every Certificate Authority in the certificate chain your service uses is has a version 3 certificate. Version 1 of X.509 has been deprecated for a long time. For each certificate authority in the chain, you can do:

     certtool -i < $CERTIFICATE | grep Version:

  2. Check that every intermediate certificate in your chain and your own end-entity certificate uses a better digest algorithm than MD5. SHA1 is widely considered an appropriate choice today. Note that the digest used in the self-signed root certificate does not matter.

     certtool -i < $CERTIFICATE | grep 'Signature Algorithm:'

  If you find any certificates using outmoded, insecure functionality, you should try to get them re-issued. For example, RapidSSL used to offer MD5-digested certificates, but now offers SHA1-digested certificates, and appears to be willing to reissue any MD5-digested certificate.
• If you are the developer or maintainer of a package that uses GnuTLS for X.509 certificate chain validation:
  1. Consider checking the details of any failed GnuTLS certificate verification, and producing a clear error message if the response is GNUTLS_CERT_INSECURE_ALGORITHM. This will help users and administrators know that the specific problem is an MD5-digested certificate.
  2. Look at the semantics of how your application populates the list of trusted certificates that is passed to GnuTLS. If your users are clearly instructed to only populate that list with Certificate Authorities (and not Peer or End-Entity certificates), then it is probably not unreasonable to accept version 1 certificates in that set. If this is the case, you can set the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag (which endorses the use of V1 certificates from the trusted certificate store as certificate authorities). It is strongly recommended that you do not set GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT (note that this is a distinct flag), because it allows previously-unknown v1 certificates to act as intermediate certs (though they may have been issued as end-entity certificates).
• If you are an end user of an application or system facility which uses GnuTLS for certificate chain validation:
  1. If you notice a GnuTLS-linked tool failing, try fetching the certificate of the remote service to see if there are any version 1 certificates in the validation chain, or if there are any non-root certificates that use a digest algorithm weaker than SHA1. Here's an example of looking at the parameters of the certificate used by https://wiki.debian.org (i'm using tools from gnutls-bin):

     0 dkg@pip:~$ echo | gnutls-cli --print-cert -p 443 wiki.debian.org | certtool -i | egrep '(Subject|Issuer|Signature Algorithm|Version):'
     	Version: 3
     	Issuer: O=Debian,CN=ca.debian.org,EMAIL=debian-admin@debian.org
     	Subject: O=Debian,CN=wiki.debian.org,EMAIL=debian-admin@debian.org
     	Signature Algorithm: RSA-SHA
     	Version: 3
     	Issuer: C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmaster@spi-inc.org
     	Subject: O=Debian,CN=ca.debian.org,EMAIL=debian-admin@debian.org
     	Signature Algorithm: RSA-SHA
     	Version: 3
     	Issuer: C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmaster@spi-inc.org
     	Subject: C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmaster@spi-inc.org
     	Signature Algorithm: RSA-SHA
     0 dkg@pip:~$ certtool -i < /usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt | egrep '(Subject|Issuer|Signature Algorithm|Version):'
     	Version: 3
     	Issuer: C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmaster@spi-inc.org
     	Subject: C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,EMAIL=hostmaster@spi-inc.org
     	Signature Algorithm: RSA-SHA
     0 dkg@pip:~$ 
     

     Note above that the web server is offering all three pieces of the certificate chain; many web servers will not bother to offer the final root certificate authority's certificate, since your client must already have that certificate if it is going to possibly consider the chain valid. So the final check above (of spi-cacert-2008.crt) was redundant for this particular parameter checking.

     You'd know there was trouble if any of the certificates (except the self-signed root) had a signature algorithm of RSA-MD5 or RSA-MD2, or if any of the certificates (except the end entity cert which identifies the service itself) was Version: 1.

     Note also that the above check just checks the specific parameters i'm concerned about in this post. There are lots of other ways that validation calculations can fail, and just because these parameters look ok does not mean that the certificate chain is actually OK. If you're getting certificate validation problems and these parameters all look OK, please ask your administrator or post a question to help-gnutls.

Above all, ask for help if things aren't working the way you expect! The people maintaining this infrastructure want it to be useful, and we also want to make sure that people depending on it for real security are not subject to compromise because of failures in deprecated parts of the cryptosystems.