I'm not sure who should fix it but having 'wget' on our default setup reject our own bugzilla seems at least silly. It also breaks app-admin/repo-commit which used to query bugzie via http://, and now gets redirected to https:// which is rejected by wget. Security in the first place, eh?
What version of wget? What version of openssl? What version of ca-certificates? And what use flags for wget?
[ebuild R ] net-misc/wget-1.14 USE="gnutls idn ipv6 pcre ssl zlib -debug -nls -ntlm -static -uuid" 0 kB [ebuild R ] dev-libs/openssl-1.0.1c USE="gmp (sse2) zlib -bindist -kerberos -rfc3779 -static-libs {-test} -vanilla" 0 kB [ebuild R ] app-misc/ca-certificates-20121114 0 kB
With USE=-gnutls, it works. Therefore, I guess the issue is specific to GnuTLS backend. [ebuild R ] net-libs/gnutls-3.1.6 USE="cxx zlib -dane -doc -examples -guile -nls -pkcs11 -static-libs {-test}" LINGUAS="-cs -de -en -fi -fr -it -ms -nl -pl -sv -uk -vi -zh_CN" 0 kB Sadly, even with USE=debug and --debug, I can't get a better description of the error.
I think I've got it: $ gnutls-cli bugs.gentoo.org 443 Processed 160 CA certificate(s). Resolving 'bugs.gentoo.org'... Connecting to '94.100.119.170:443'... - Certificate type: X.509 - Got a certificate list of 4 certificates. - Certificate[0] info: - subject `C=US,ST=New Mexico,L=Albuquerque,O=GENTOO Foundation\, Inc.,OU=Gentoo Infrastructure,CN=bugs.gentoo.org', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA1, activated `2011-06-20 01:43:02 UTC', expires `2013-06-19 01:43:02 UTC', SHA-1 fingerprint `ed7f4fa0f86a3f08fa456c8f18b7fa4d2dbbaceb' Public Key Id: 7dce97e4e3f59dff13412407c4e92e5fdccd9912 Public key's random art: +--[ RSA 1024]----+ | o++o | | oo. | | . . | | . E . | | S . o +.*| | = = B+| | = B o| | + ++| | ..O| +-----------------+ - Certificate[1] info: - subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33' - Certificate[2] info: - subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d' - Certificate[3] info: - subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org', RSA key 4096 bits, signed using RSA-SHA256, activated `2011-05-23 17:48:02 UTC', expires `2021-05-20 17:48:02 UTC', SHA-1 fingerprint `ad7c3f64fc4439fef4e90be8f47c6cfa8aadfdce' - Status: The certificate is NOT trusted. The certificate chain uses insecure algorithm. *** Verifying server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate. As far as I understand, it doesn't like the root cert (it says 'broken!' near the algo there…).
Well, I'm not sure who should take an action here. @infra, can we somehow replace that certificate with a better-signed one? Or shall we mangle gnutls not to reject it?
See also bug 256437. If I read the bugs right this is due to a change on the gnutls side, though: the change made to get gnutls-cli to accept the certificate chain no longer seems to be doing the trick. robbat2 might know what's going on here, and if there's a safe fix (that doesn't break older non-gnutls clients).
md5 hash is broken, there were practical attacks to that used this. Although checking the signature on root certificate is somewhat redundant as the endpoint has a full copy of the root certificate. But in the generic case it is better not to have any md5 signed certificate anywhere these days.
(In reply to comment #6) > See also bug 256437. If I read the bugs right this is due to a change on the > gnutls side, though: the change made to get gnutls-cli to accept the > certificate chain no longer seems to be doing the trick. robbat2 might know > what's going on here, and if there's a safe fix (that doesn't break older > non-gnutls clients). From the cacert site I understand that the MD5-signed certificates should have expired by now. Does it mean that this didn't involve their root cert or do we have some kind of outdated version?
I don't see the certificate that is actually used is expired... Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org Validity Not Before: Mar 30 12:29:49 2003 GMT Not After : Mar 29 12:29:49 2033 GMT Subject: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org
BUT... if they just resigned their root certificate with different digest, users may use the new certificate without change to the issued certificates. However the authority information access refers to http://www.CAcert.org/ca.crt, which still downloads the md5 signed root.
Just as an FYI, 'mangling gnutls to accept MD5 certs' is wrong. Please don't do it. I'm unsure anyone except robin has enough CACert points to generate a new bugs cert (I know I do not.) -A
our cert itself uses SHA1, it's one of the CA intermediate's that uses MD5. I don't know of any replacement issued by upstream for it, despite what they say.
(In reply to Robin Johnson from comment #12) > our cert itself uses SHA1, it's one of the CA intermediate's that uses MD5. > I don't know of any replacement issued by upstream for it, despite what they > say. https://www.sixxs.net/ uses CAcert Class 3 and works with gnutls-cli and wget.
*** This bug has been marked as a duplicate of bug 256437 ***
