bootstrap.sh fails when using wget, due to a certificate issue

[TravisCardwell]

When using bootstrap.sh to install cabal-install, and wget is used to fetch packages, the installation fails with the following error message:

Connecting to hackage.haskell.org (hackage.haskell.org)|88.198.224.242|:443... connected.
ERROR: The certificate of `hackage.haskell.org` is not trusted.
ERROR: The certificate of `hackage.haskell.org` hasn't got a known issuer.

Error during cabal-install bootstrap.
Failed to download Cabal.

Inspection of the https://hackage.haskell.org/ certificate with Firefox confirms that identity information is not trusted.

The issue was introduced in 41d52be (Bootstrap over HTTPS.).

Systems with curl installed do not have this error, as curl does not complain about the certificate.

I can think of two ways to resolve this issue without reverting to HTTP. One is to replace the https://hackage.haskell.org/ certificate with one that is trusted. Alternatively, the --no-check-certificate option can be added to the wget command, instructing it to ignore the error.

   elif which ${WGET} > /dev/null
   then
-    ${WGET} -c ${URL} || die "Failed to download ${PKG}."
+    ${WGET} --no-check-certificate -c ${URL} || die "Failed to download ${PKG}."
   elif which ${FETCH} > /dev/null

---

Test environment:

• Debian Wheezy (stable); minimal virtual machine
• amd64
• GHC 7.8.2
• cabal-install version 1.20.0.0

[tibbe]

A somewhat naive question: why isn't the certificate trusted? Chrome doesn't give me much info about the certificate, more than it's issued by GlobalSign.

[thoughtpolice]

The certificate IS signed by CA, in this case, GlobalSign. They issued us a wildcard certificate as an OSS project - but it is not 'trusted' in the sense it does not have identity validation of the haskell.org domain (i.e. they did not directly verify the registrant as the representative for the organization, which typically requires physical correspondence and possibly paperwork on behalf of Haskell.org.)

Ideally, what we would actually have is an EV wildcard certificate, which would essentially offer the highest degree of identity verification on behalf of us, while still allowing us to have multiple domains secured by HTTPS at our discretion. Unfortunately those are going to run us anywhere from a few hundred to a thousand dollars a year (USD) or more, depending on the CA you go with.

[thoughtpolice]

I'll also note that in this case, the fact wget doesn't seem to have a distinction between "this certificate is signed by a CA in my root store" and "this certificate does not have full identity verification" is rather annoying. I imagine curl is more lenient and doesn't require identity verification, but at minimum requires a legitimate signature on the cert.

[tibbe]

I'm leaning towards --no-check-certificate then. Our certificate is good enough for the browser, so it should be good enough for wget. Anyone want to prepare a pull request?

[tibbe]

Fixed by 4167869.

[dagit]

@TravisCardwell What version of wget are you using?

I think this is a wget bug:

• curl works for you, so probably not an issue of missing the CA certs
• wget older than 1.14 lacks SNI support: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653267
• I have 1.14 on two different machines (OSX mavericks and Fedora 19) and I'm able to wget https://hackage.haskell.org/ without errors.
• This ssl checker says that the cert should work: http://www.sslshopper.com/ssl-checker.html#hostname=hackage.haskell.org

[TravisCardwell]

I am using wget as packaged for Debian stable: https://packages.debian.org/wheezy/wget

The current version is based on 1.13.4, but SNI support appears to have been backported: http://metadata.ftp-master.debian.org/changelogs//main/w/wget/wget_1.13.4-3+deb7u1_changelog

[dagit]

Interesting. When I google, I do see at least one case where that version of wget still fails when 1.14 works: Hexxeh/rpi-update#65 (comment)

@TravisCardwell Sorry to trouble you, but would you be willing to build wget 1.14 from source just to see if it works for you with hackage? If not I'll need to create a debian vm so I can reproduce it.

[TravisCardwell]

@dagit No problem. I just booted a minimal VM and did some tests. With wget 1.14 built from source, I got the same error. I was going to install curl to do that test as well, and I noticed that the installation pulls ca-certificates as well! Aborting the curl installation, I installed ca-certificates and tested wget. Version 1.14 worked, so I reverted back to the packaged version, and it works as well!

The real issue is that ca-certificates was not installed. While wget is included in a minimal Debian install, ca-certificates is not. The Firefox security warning is apparently unrelated. I am sorry for not noticing that earlier!

@tibbe Shall I prepare a pull request to revert #1798?

[tibbe]

@TravisCardwell you mean reverting the use of --no-check-certificate? I don't quite understand how that causes failures when ca-certificates is not installed. Isn't the whole point of the flag that certificates aren't checked so the presence of ca-certificates shouldn't matter?

[23Skidoo]

Sounds like a bug in Debian then - wget should depend on (or at least recommend) ca-certificates.

[TravisCardwell]

@tibbe The presence of --no-check-certificate does not cause failures; it just negates one of the benefits of using SSL: avoidance of man-in-the-middle attacks. Since installing ca-certificates solves this issue, it might be preferable to go ahead and check certificates.

[23Skidoo]

I've reverted this patch. If anyone wants to file a bug report for Debian, feel free to do so.

[TravisCardwell]

@23Skidoo I have emailed the wget package maintainer.