It works with all major browsers but fails using wget: wget "https://www.thc.org/download.php?t=r&f=thc-pptp-bruter-0.1.4.tar.gz" --2013-10-21 11:22:51-- https://www.thc.org/download.php?t=r&f=thc-pptp-bruter-0.1.4.tar.gz Resolving www.thc.org... 199.58.210.16 Connecting to www.thc.org|199.58.210.16|:443... connected. ERROR: cannot verify www.thc.org's certificate, issued by ‘/C=US/O=GeoTrust, Inc./CN=RapidSSL CA’: Unable to locally verify the issuer's authority. To connect to www.thc.org insecurely, use `--no-check-certificate'. https://www.ssllabs.com/ssltest/analyze.html?d=thc.org ssllabs tests shows that the cert has "Extra download" RapidSSL CA. Does it mean that wget should support that extra download feature?..
Er, thc.org needs to fix the certificate or you do what wget suggests (at your own risk, of course). There is certainly a "bug" here, but Gentoo can't fix it for thc.org....
I think your missed the point that it works for any other browsers including s_client: bash$ openssl s_client -connect www.thc.org:443 So it is the wget bug.
I'm wrong, the s_client reports the error : verify error:num=21:unable to verify the first certificate Verify return code: 21 (unable to verify the first certificate) Wget uses it probably, so it should be the issue with openssl instead
Install and/or upgrade ca-certificates, then use --ca-directory=... with wget to point to the right directory; does that work? The errors are somewhat vague, I wonder if you can get more output by using the --debug parameter; as now it only says it is unable to verify, but it doesn't say why that is the case. Maybe with --debug it does.
(In reply to Anton Bolshakov from comment #3) > I'm wrong, the s_client reports the error : > verify error:num=21:unable to verify the first certificate > Verify return code: 21 (unable to verify the first certificate) > > Wget uses it probably, so it should be the issue with openssl instead # curl 'https://www.thc.org/download.php?t=r&f=thc-pptp-bruter-0.1.4.tar.gz' -o thc-pptp-bruter-0.1.4.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. So all your web browsers "work" fine and only curl and wget and something called s_client complain?
ok, upgrading to the latest app-misc/ca-certificates-20130906 didn't help. I found a random website signed by the same cert: https://ssltest12.bbtest.net/ where wget is able to connect. There are two differences with the setup: ssltest12 configured with 2 additional certs in the chain and thc.org has 2 undefined fields: Organization (O) <Not Part Of Certificate> Organizational Unit (OU) <Not Part Of Certificate> Also, there is a different error with -issuer_checks: openssl s_client -connect www.thc.org:443 -issuer_checks verify error:num=29:subject issuer mismatch
ok, thc fixed the cert issue: >I previously concatenated the rapidssl intermediate CA file to the cert (that's >the correct way by openssl). But for apache this did not work (apache only read >the first certificate in the server certificate - doh). I had to specify it >explicit as SSLCertificateChainFile. Since I'm not sure is it a bug in the openssl or it is more stricted, I'm closing the bug for now.
