"certificate has unknown CA" error getting repos

[creswick]

Both userRepos and organizationRepos cause this 'unknown CA' error. Here's a minimal test case:

module Main where
import Github.Repos

main :: IO ()
main = print =<< userRepos "creswick" All

Results in:

Left (HTTPConnectionError (HandshakeFailed (Error_Protocol ("certificate has unknown CA",True,UnknownCa))))

Here's my complete set of installed dependencies, in the event this is specific to certain versions of libraries:

/home/creswick/myapps/haskell/ghc-7.0.3/lib/ghc-7.0.3/package.conf.d
   Cabal-1.10.1.0
   array-0.3.0.2
   base-4.3.1.0
   bin-package-db-0.0.0.0
   bytestring-0.9.1.10
   containers-0.4.0.0
   directory-1.1.0.0
   extensible-exceptions-0.1.1.2
   ffi-1.0
   filepath-1.2.0.0
   ghc-7.0.3
   ghc-binary-0.5.0.2
   ghc-prim-0.2.0.0
   haskell2010-1.0.0.0
   haskell98-1.1.0.1
   hpc-0.5.0.6
   integer-gmp-0.2.0.3
   old-locale-1.0.0.2
   old-time-1.0.0.6
   pretty-1.0.1.2
   process-1.0.1.5
   random-1.0.0.3
   rts-1.0
   template-haskell-2.5.0.0
   time-1.2.0.3
   unix-2.4.2.0
/home/creswick/development/github-backup/cabal-dev/packages-7.0.3.conf
   HTTP-4000.2.2
   aeson-0.6.0.0
   asn1-data-0.6.1.3
   attoparsec-0.10.1.0
   attoparsec-conduit-0.2.0.1
   attoparsec-enumerator-0.3
   base-unicode-symbols-0.2.2.3
   base64-bytestring-0.1.1.1
   blaze-builder-0.3.1.0
   blaze-builder-conduit-0.2.0.1
   case-insensitive-0.4.0.1
   cereal-0.3.5.1
   certificate-1.1.1
   conduit-0.2.2
   cookie-0.4.0
   cprng-aes-0.2.3
   crypto-api-0.9
   crypto-pubkey-types-0.1.1
   cryptocipher-0.3.0
   cryptohash-0.7.4
   data-default-0.3.0
   deepseq-1.3.0.0
   dlist-0.5
   entropy-0.2.1
   enumerator-0.4.18
   failure-0.2.0.1
   github-0.2.1
   hashable-1.1.2.3
   http-conduit-1.2.6
   http-types-0.6.10
   largeword-1.0.1
   lifted-base-0.1.0.3
   monad-control-0.3.1.1
   mtl-2.0.1.0
   network-2.3.0.11
   parsec-3.1.2
   primitive-0.4.1
   regex-base-0.93.2
   regex-compat-0.95.1
   regex-posix-0.95.1
   safe-0.3.3
   semigroups-0.8
   socks-0.4.1
   syb-0.3.6
   tagged-0.2.3.1
   text-0.11.1.13
   tls-0.9.2
   tls-extra-0.4.3
   transformers-0.2.2.0
   transformers-base-0.4.1
   unordered-containers-0.1.4.6
   uri-0.1.6
   utf8-string-0.3.7
   vector-0.9.1
   zlib-0.5.3.3
   zlib-bindings-0.0.3.2
   zlib-conduit-0.2.0.1

[vincenthz]

This is an issue of the underlaying tls stack and what the error tell you is that it can't find a certificate in your certificate storage that verify the certificate chain received from github. Since you're exercising the verifying code path, i assume you're running linux (or unix), and the only place where tls (one of its sub package certificate) is going to check is in /etc/ssl/certs/.

[creswick]

@vincenthz I am running Linux -- it sounds like I I either need to:

• Install a new cert somewhere (?)
• Use a non-verifying code path
• ??

I'm not sure how to do either of these things; digging in the source for the github bindings, it doesn't look like https can be disabled, which I'm assuming is the reason a cert is needed at all... do you have suggestions?

[vincenthz]

can you send the list of certificate in /etc/ssl/certs. also can you run the following tool (and send the output as well) from the tls-debug package:

tls-retrievecertificate -d <destination> -p <port> -v -c

where destination is probably api.github.com and port is 443.

[creswick]

 $ ls -l /etc/ssl/certs/
total 1380
-rw-r--r--. 1 root root 660107 Sep  1  2011 ca-bundle.crt
-rw-r--r--. 1 root root 738643 Sep  1  2011 ca-bundle.trust.crt
-rwxr-xr-x. 1 root root    610 Jan 19 08:37 make-dummy-cert
-rw-r--r--. 1 root root   2242 Jan 19 08:37 Makefile

Here's the output of the tls command:

 $ ./cabal-dev/bin/tls-retrievecertificate -d api.github.com -p 443 -v -c
connecting to api.github.com on port 443 ...
###### Certificate 1 ######
serial:   1238043465561584
issuer:   [([2,5,4,3],(Printable,"Go Daddy Secure Certification Authority")),([2,5,4,5],(Printable,"07969287")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Scottsdale")),([2,5,4,8],(Printable,"Arizona")),([2,5,4,10],(Printable,"GoDaddy.com, Inc.")),([2,5,4,11],(Printable,"http://certificates.godaddy.com/repository"))]
subject:  [([2,5,4,3],(Printable,"*.github.com")),([2,5,4,10],(Printable,"*.github.com")),([2,5,4,11],(Printable,"Domain Control Validated"))]
validity: (2009-12-11,18156s,True) to (2014-12-11,18156s,True)
###### Certificate 2 ######
serial:   769
issuer:   [([2,5,4,6],(Printable,"US")),([2,5,4,10],(Printable,"The Go Daddy Group, Inc.")),([2,5,4,11],(Printable,"Go Daddy Class 2 Certification Authority"))]
subject:  [([2,5,4,3],(Printable,"Go Daddy Secure Certification Authority")),([2,5,4,5],(Printable,"07969287")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Scottsdale")),([2,5,4,8],(Printable,"Arizona")),([2,5,4,10],(Printable,"GoDaddy.com, Inc.")),([2,5,4,11],(Printable,"http://certificates.godaddy.com/repository"))]
validity: (2006-11-16,6877s,True) to (2026-11-16,6877s,True)
###### Certificate 3 ######
serial:   269
issuer:   [([1,2,840,113549,1,9,1],(IA5,"[email protected]")),([2,5,4,3],(Printable,"http://www.valicert.com/")),([2,5,4,7],(Printable,"ValiCert Validation Network")),([2,5,4,10],(Printable,"ValiCert, Inc.")),([2,5,4,11],(Printable,"ValiCert Class 2 Policy Validation Authority"))]
subject:  [([2,5,4,6],(Printable,"US")),([2,5,4,10],(Printable,"The Go Daddy Group, Inc.")),([2,5,4,11],(Printable,"Go Daddy Class 2 Certification Authority"))]
validity: (2004-06-29,61580s,True) to (2024-06-29,61580s,True)
###### Certificate 4 ######
serial:   1
issuer:   [([1,2,840,113549,1,9,1],(IA5,"[email protected]")),([2,5,4,3],(Printable,"http://www.valicert.com/")),([2,5,4,7],(Printable,"ValiCert Validation Network")),([2,5,4,10],(Printable,"ValiCert, Inc.")),([2,5,4,11],(Printable,"ValiCert Class 2 Policy Validation Authority"))]
subject:  [([1,2,840,113549,1,9,1],(IA5,"[email protected]")),([2,5,4,3],(Printable,"http://www.valicert.com/")),([2,5,4,7],(Printable,"ValiCert Validation Network")),([2,5,4,10],(Printable,"ValiCert, Inc.")),([2,5,4,11],(Printable,"ValiCert Class 2 Policy Validation Authority"))]
validity: (1999-06-26,1194s,True) to (2019-06-26,1194s,True)
### certificate chain trust
chain validity : rejected: CertificateRejectUnknownCA
time validity : accepted

Thanks!

[vincenthz]

Thanks. i understand the issue now. The issue is the certificate package doesn't understand this way to store certificate (in one big file).

I'll fix it in the near future, however to workaround the problem right now you can just take the certificate at the end of the chain (which is "ValiCert Class 2 Policy") from the ca-bundle.crt, and copy paste the ----- BEGIN TRUSTED CERTIFICATE ---- .... till ----- END TRUSTED CERTIFICATE ---- into one file in /etc/ssl/certs and remove the "TRUSTED" word from the BEGIN and END lines.

[creswick]

Thanks! That did the trick.

(Minor note: the crt file, in Fedora at least, doesn't have the "TRUSTED" word -- and the "untrusted" ? cert worked for this.)

[vincenthz]

This is ok. my system certificate doesn't have the TRUSTED keyword either. it's no more trusted if it has the TRUSTED word in it. it just looks like there's lots of different format variations, that all do the same things .. but make the production of solid code that works in all condition much more complicated :(

[ronslow]

Vincent
Just to be clear on this. The certificate module currently requires each certificate to be stored in a separate file in /etc/ssl/certs
Is there any restriction on the file name?
I still cannot get api.twitter.com to validate. I have placed 2 files in /etc/ssl/certs - one is called VeriSign Class 3 Secure Server CA - G2.cer and the other is called Verisign Trust Network.cer
These contain the relevant certificates starting ----BEGIN CERTIFICATE and ending -----END CERTIFICATE.
They are certificates in Base64 encoded X509 form
Robert

[vincenthz]

Yes, at the moment certificate requires one file per certificate; there's no restrictions on the file name (except that it need to valid utf8). can you please send me the actual files you've created ?

[ronslow]

Vincent
Here are the two files in /etc/ssl/certs, tar'd for transmission

Robert

-----Original Message-----
From: Vincent Hanquez
Sent: Monday, April 16, 2012 10:26 AM
To: ronslow
Subject: Re: [github] "certificate has unknown CA" error getting repos (#20)

Yes, at the moment certificate requires one file per certificate; there's no
restrictions on the file name (except that it need to valid utf8). can you
please send me the actual files you've created ?

---

Reply to this email directly or view it on GitHub:
https://github.com/mike-burns/github/issues/20#issuecomment-5148746

[vincenthz]

I don't see any tar files. might be github preventing tar file to be attached. please send it to my email address [email protected].

[vincenthz]

The multiple certificates in one file issue should be now fixed in certificate-1.2.0, tls-0.9.3 and tls-extra-0.4.5.

Apologies to mike for squating the github repository issue tracker :-)

[mike-burns]

Glad this all got resolved while I was traveling!

[ronslow]

Solved for me with certificate-1.2.0, tls-0.9.3 and tls-extra-0.4.5
Thanks Vincent
Robert

[creswick]

I've been unable to build with certificate-1.2 due to changes in http-conduit's api -- see #21 for details.

Thanks!

[BenChand]

I've been having this issue too, not really sure what I'm doing wrong with a fresh install.