At the moment, all gnutls ebuilds have the pkcs11 disabled by default. This makes it unable to verify certificates, breaking HTTPS support for at least wget (and thus wgetpaste) with USE=gnutls, lynx with USE=gnutls, and curl with CURL_SSL="gnutls". As such, gnutls should have USE=+pkcs11 by default to avoid such issues.
(In reply to Dainius Masiliūnas from comment #0) > At the moment, all gnutls ebuilds have the pkcs11 disabled by default. This > makes it unable to verify certificates, breaking HTTPS support for at least > wget (and thus wgetpaste) with USE=gnutls, lynx with USE=gnutls, and curl > with CURL_SSL="gnutls". > Do you have some additional information on this? PKCS#11 isn't a requirement for certificate validation, and most of my installs are without this use flag without experiences any issue. > As such, gnutls should have USE=+pkcs11 by default to avoid such issues. The issues are likely not related to this to begin with and enabling the use flag by default would only increase the number of dependencies unnecessarily.
Interesting... The first time when I tried to solve the issue, remerging gnutls with that USE flag made certificate validation work, seemingly, but now I once again have problems with it, even though that USE flag is on again. So it looks like you're right, the root of the issue is somewhere else. For instance, curl gives me this: $ curl https://bpaste.net curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none 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 And wget gives me this: $ wget https://bpaste.net --2016-02-29 19:06:08-- https://bpaste.net/ Resolving bpaste.net... 84.22.98.66, 2a02:2770:13:0:21a:4aff:fef3:978 Connecting to bpaste.net|84.22.98.66|:443... connected. ERROR: The certificate of 'bpaste.net' is not trusted. ERROR: The certificate of 'bpaste.net' has expired. This does not seem to happen when using the OpenSSL backend.
(In reply to Dainius Masiliūnas from comment #2) > Interesting... The first time when I tried to solve the issue, remerging > gnutls with that USE flag made certificate validation work, seemingly, but > now I once again have problems with it, even though that USE flag is on > again. So it looks like you're right, the root of the issue is somewhere > else. > > For instance, curl gives me this: > > $ curl https://bpaste.net > curl: (60) server certificate verification failed. CAfile: > /etc/ssl/certs/ca-certificates.crt CRLfile: none > More details here: http://curl.haxx.se/docs/sslcerts.html > > Has it been long since you updated app-misc/ca-certificates? > > And wget gives me this: > > $ wget https://bpaste.net > > --2016-02-29 19:06:08-- https://bpaste.net/ > > Resolving bpaste.net... 84.22.98.66, 2a02:2770:13:0:21a:4aff:fef3:978 > > Connecting to bpaste.net|84.22.98.66|:443... connected. > > ERROR: The certificate of 'bpaste.net' is not trusted. > > ERROR: The certificate of 'bpaste.net' has expired. This is a different issue, although the certificate I encounter doesn't expire until 2017. Try getting a copy of that certificate and to be sure verify that your local clock is set correctly.
The certificates are the latest stable (20151214.3.21), and the clocks are set correctly and synchronised via NTP.
