Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


regression from security fix in 15885c0649ceabd2f4d2913df8ac6dc63d6b3b37 #32

joeyh opened this Issue · 5 comments

2 participants


This security fix seems to have caused a regression in checking the certificate of

One easy way to see the problem is using DAV's hdav command, which is here built using haskell-tls-extra

joey@gnu:~/tmp/haskell-dav-0.3/dist/build/hdav>./hdav getprops --username=foo --password=foo
hdav: HandshakeFailed (Error_Protocol ("certificate rejected: certificate is not allowed to sign another certificate",True,CertificateUnknown))

Checking the same url with Chrome, Firefox, and wget, none of them have a problem with its certificate chain. While I can't rule out the possibility that they're all vulnerable to the same hole that was fixed, it seems more lilkely that the fix made to hs-tls was buggy.


Another url that fails is
And ....


This only seems to affect the backport. Testing with 0.6.1, it's ok.

Perhaps the backported code depends on a newer version of some other library, such as certificate?


Ouch. That's unfortunate, look like that was a bad idea afterall to backport the security fix. I don't have the resource to support old versions of tls, but i would accept patches. If you really rely on this very old debian version, one easy thing to try is use the tls-retrievecertificate from tls-debug with all the necessary debugging/verbose options, and check manually what's the actual reason of the failure. As you said, the certificate library would play a role here and might need some patching relative to the key usage extension. for example hs-certificate:a156d857189fc880f7d0a2de3310e750994c766b.


Thank for the hint, vincent. I tried backporting certificate:a156d857189fc880f7d0a2de3310e750994c766b onto hs-certificate 1.2.3, which worked easily. I then had to make a minor change to tls-extra- to handle the new field.

This seems to have mostly worked; tls-retrievecertificate works as expected for properly signed certificates including And it fails properly for sites with self-signed or snakeoil certificates.

I did find one problem; it doesn't like's certificate:

chain validity : rejected: CertificateRejectOther "certificate is not allowed to sign another certificate"

However, I just checked the current version of tls-, and they *also reject that site. So perhaps that's a separate bug you should look at. (At least Chromium has no trouble with its cert chain.)


thanks. i just reproduced it now, definitely another bug lurking.

@vincenthz vincenthz closed this issue from a commit
@vincenthz certificate without key usage extension are automatically assumed to be
allowed to cert sign and crl sign.

fix #32.
@vincenthz vincenthz closed this in fd7caae
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.