search

haskell-github / github

The github API for Haskell
https://hackage.haskell.org/package/github
BSD 3-Clause "New" or "Revised" License
411 stars 190 forks source link

"certificate has unknown CA" error getting repos #20

Closed creswick closed 12 years ago

creswick commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

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 commented 12 years ago

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 commented 12 years ago 
 $ 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,"info@valicert.com")),([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,"info@valicert.com")),([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,"info@valicert.com")),([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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

I don't see any tar files. might be github preventing tar file to be attached. please send it to my email address tab@snarc.org.

vincenthz commented 12 years ago

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 commented 12 years ago

Glad this all got resolved while I was traveling!

ronslow commented 12 years ago

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

creswick commented 12 years ago

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

Thanks!

BenChand commented 9 years ago

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