As the operator of the website mtgox.com I had some users reporting that using curl to access our API on https://mtgox.com/ they had SSL errors, which forced some of them to ignore all SSL errors altogether. After some research we found that the following works just fine: wget http://curl.haxx.se/ca/cacert.pem curl --cacert cacert.pem https://mtgox.com It seems that the issue is that the CA certificate used by our website (Verisign, which should be common enough) is not in the ca-certificates shipped by Gentoo anymore (but in the one shipped by curl). Note that at this time most browsers are known to connect fine to our website too, even on such gentoo versions (I would guess NSS is using a different certificate store). Reproducible: Always Steps to Reproduce: 1. curl https://mtgox.com Actual Results: curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html Expected Results: Lots of HTML Some users have reported a similar issue with latest Ubuntu. Users on Redhat and Debian have not reported this issue yet.
jer@wieneke ~ $ curl 'https://mtgox.com/' curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 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.
I initially thought about filing this for curl, however it looks more like a CA issue (ie. curl not finding the right CA). When using the cacert.pem file distributed by curl it works fine, so it's not really a problem in curl itself, unless that behavior is not supposed to happen (in which case it could be a bug in openssl, too).
> Steps to Reproduce: > 1. curl https://mtgox.com > Actual Results: > curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed > More details here: http://curl.haxx.se/docs/sslcerts.html > I'm not reproducing this at all. curl https://mtgox.com works just fine right now. If this is still a problem, please run curl with verbose tracing and report here. For good measure, let's see your "emerge --info curl". Otherwise, I'll close after a while.
Hi, To reproduce you need last version (~x86 or ~amd64) of ca-certificates. Haven't tested when compiling curl against gnutls instead of openssl yet. Portage 2.1.10.44 (default/linux/amd64/10.0/desktop, gcc-4.5.3, glibc-2.14.1-r2, 3.1.4-gentoo-tux x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.1.4-gentoo-tux-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.1 Timestamp of tree: Sun, 11 Mar 2012 04:30:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.7 [disabled] app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.4.6, 2.5.4-r4, 2.6.7-r2, 2.7.2-r3, 3.1.4-r3, 3.2.2 dev-util/ccache: 3.1.7 dev-util/cmake: 2.8.7-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.8.2 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.2-r1 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.4.6-r1, 4.5.3-r2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.2 (virtual/os-headers) sys-libs/glibc: 2.14.1-r2 Repositories: gentoo magicaltux-ebuilds x-portage ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA PUEL skype-eula dlj-1.1 sun-bcla-java-vm googleearth AdobeFlash-10.1 Oracle-BCLA-JavaSE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona -mtune=nocona" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=nocona -mtune=nocona" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://ftp.iij.ad.jp/pub/linux/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en fr ja" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/magicaltux /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 bash-completion berkdb bluetooth branding bzip2 cairo cdda cdr cjk cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam ffmpeg firefox flac fortran gdbm gdu gif gnome gnome-keyring gpm gtk iconv ipv6 jpeg lcms libnotify mad mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pam pango pcre pdf png policykit ppds pppd qt3support qt4 readline sdl session spell sse sse2 ssl ssse3 startup-notification svg sysfs tcpd tiff truetype udev unicode usb vdpau vorbis x264 xcb xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2 canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en fr ja" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= net-misc/curl-7.24.0 was built with the following: USE="(multilib) ssl -ares -gnutls -idn -ipv6 -kerberos -ldap -nss -ssh -static-libs -test -threads"
Thanks, that last post gave me all the pieces to reproduce. What's triggering this is USE="ssl -gnutls -nss" with more recent ca-certificates. It affects at least curl 7.24.0 and 7.25.0. Here's what I found: ca-certificates-20090709 - OK >=ca-certificates-20110421 - FAIL and of course using curl --cacert cacert.pem using the cacert obtained from http://curl.haxx.se/ca/cacert.pem works. That one derives from mozilla's bundle according to http://curl.haxx.se/docs/caextract.html. Also this does not have anything to do mtgox.com. I get the failure with a server I operate with cert signed by Verisign: curl https://ddl.dyc.edu Okay, I'm inclinded to agree. This has to do with what we're bundling (or not bundling) with our ca-certificates. @base-system. Opinions?
blueness: Your server at https://ddl.dyc.edu is missing part of the CA Chain. The cert you have their claims: Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Secure Server CA - G3 That certificate is NOT in ca-certificates at all. The closest match is: Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 1999 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G3 Your server should give out a full CA Chain.
The chain for mtgox is correctly configured, with: 0 s:/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0110-01-069784/C=JP/ST=Tokyo/L=Suginami/O=K.K. Tibanne/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mtgox.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority This one is a lot more interesting as a bug. The very list item in the chain, has the issuer of: C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority Which _is_ in the ca-certificates package: /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt Let's test it with various clients: GnuTLS: ======= # gnutls-cli \ --x509cafile /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt \ --port 443 \ mtgox.com ... Processed 1 CA certificate(s). Resolving 'mtgox.com'... Connecting to '72.52.5.67:443'... ... - The hostname in the certificate matches 'mtgox.com'. - Peer's certificate is trusted - Version: TLS1.0 NSS: ==== Unfortunetly doesn't have much in the way of useful debug output. # vfyserv -p 443 mtgox.com -c Connecting to host mtgox.com (addr 72.52.5.67) on port 443 Cert file cert.000 was created. Cert file cert.001 was created. Cert file cert.002 was created. Cert file cert.003 was created. Handshake Complete: SERVER CONFIGURED CORRECTLY # openssl x509 -inform DER -in cert.000 -noout -text # openssl x509 -inform DER -in cert.001 -noout -text # openssl x509 -inform DER -in cert.002 -noout -text # openssl x509 -inform DER -in cert.003 -noout -text cert.003 is important here. The mtgox server did not send that one. NSS took it from the system. OpenSSL: ======== This is where it gets really interesting
The OpenSSL output is a bit larger, and it fails because OpenSSL is not chasing the referal beyond depth 2 properly. $ openssl s_client -connect mtgox.com:443 -CAfile /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt -verify 10 verify depth is 10 CONNECTED(00000003) depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=20:unable to get local issuer certificate verify return:1 depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=27:certificate not trusted verify return:1 depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL SGC CA verify return:1 depth=0 1.3.6.1.4.1.311.60.2.1.3 = JP, businessCategory = Private Organization, serialNumber = 0110-01-069784, C = JP, ST = Tokyo, L = Suginami, O = K.K. Tibanne, OU = Terms of use at www.verisign.com/rpa (c)05, CN = mtgox.com verify return:1 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0110-01-069784/C=JP/ST=Tokyo/L=Suginami/O=K.K. Tibanne/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mtgox.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- subject=/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0110-01-069784/C=JP/ST=Tokyo/L=Suginami/O=K.K. Tibanne/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mtgox.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA --- No client certificate CA names sent --- SSL handshake has read 4546 bytes and written 521 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: 080DC4154478844A82080273689118B21E3BC513601F95A812100C1179C51F34 Session-ID-ctx: Master-Key: A6C4C7B9CEFE464632518099DCD43202E71347F2BF31F211425F378F0604967C0778A7437373766F89504E5BAB42139E Key-Arg : None PSK identity: None PSK identity hint: None Start Time: 1332711569 Timeout : 300 (sec) Verify return code: 27 (certificate not trusted) ---
If we tell OpenSSL to try and find the CA cert on it's own, it does do so properly still. # strace -ff openssl s_client -connect mtgox.com:443 -CApath /etc/ssl/certs/ -verify 10 2>&1 | egrep '^open.*(ssl|cert)' open("/usr/lib64/libssl.so.1.0.0", O_RDONLY) = 3 open("/etc/ssl/openssl.cnf", O_RDONLY) = 3 open("/etc/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ssl/certs//415660c1.0", O_RDONLY) = 4 # readlink -f -v /etc/ssl/certs//415660c1.0 /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt So I think it's OpenSSL that's been buggy in chasing referrals.
Now here's something interesting. cert.003.pem is the converted DER cert from NSS. /etc/ssl/certs//415660c1.0 is the PEM cert from ca-certificates. I thought they were identical before, but they are very similar only. $ openssl x509 -in cert.003.pem -noout -text Certificate: Data: Version: 1 (0x0) Serial Number: 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf Signature Algorithm: md2WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Validity Not Before: Jan 29 00:00:00 1996 GMT Not After : Aug 1 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c9:5c:59:9e:f2:1b:8a:01:14:b4:10:df:04:40: db:e3:57:af:6a:45:40:8f:84:0c:0b:d1:33:d9:d9: 11:cf:ee:02:58:1f:25:f7:2a:a8:44:05:aa:ec:03: 1f:78:7f:9e:93:b9:9a:00:aa:23:7d:d6:ac:85:a2: 63:45:c7:72:27:cc:f4:4c:c6:75:71:d2:39:ef:4f: 42:f0:75:df:0a:90:c6:8e:20:6f:98:0f:f8:ac:23: 5f:70:29:36:a4:c9:86:e7:b1:9a:20:cb:53:a5:85: e7:3d:be:7d:9a:fe:24:45:33:dc:76:15:ed:0f:a2: 71:64:4c:65:2e:81:68:45:a7 Exponent: 65537 (0x10001) Signature Algorithm: md2WithRSAEncryption bb:4c:12:2b:cf:2c:26:00:4f:14:13:dd:a6:fb:fc:0a:11:84: 8c:f3:28:1c:67:92:2f:7c:b6:c5:fa:df:f0:e8:95:bc:1d:8f: 6c:2c:a8:51:cc:73:d8:a4:c0:53:f0:4e:d6:26:c0:76:01:57: 81:92:5e:21:f1:d1:b1:ff:e7:d0:21:58:cd:69:17:e3:44:1c: 9c:19:44:39:89:5c:dc:9c:00:0f:56:8d:02:99:ed:a2:90:45: 4c:e4:bb:10:a4:3d:f0:32:03:0e:f1:ce:f8:e8:c9:51:8c:e6: 62:9f:e6:9f:c0:7d:b7:72:9c:c9:36:3a:6b:9f:4e:a8:ff:64: 0d:64 $ openssl x509 -in /etc/ssl/certs//415660c1.0 -noout -text Certificate: Data: Version: 1 (0x0) Serial Number: 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Validity Not Before: Jan 29 00:00:00 1996 GMT Not After : Aug 2 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c9:5c:59:9e:f2:1b:8a:01:14:b4:10:df:04:40: db:e3:57:af:6a:45:40:8f:84:0c:0b:d1:33:d9:d9: 11:cf:ee:02:58:1f:25:f7:2a:a8:44:05:aa:ec:03: 1f:78:7f:9e:93:b9:9a:00:aa:23:7d:d6:ac:85:a2: 63:45:c7:72:27:cc:f4:4c:c6:75:71:d2:39:ef:4f: 42:f0:75:df:0a:90:c6:8e:20:6f:98:0f:f8:ac:23: 5f:70:29:36:a4:c9:86:e7:b1:9a:20:cb:53:a5:85: e7:3d:be:7d:9a:fe:24:45:33:dc:76:15:ed:0f:a2: 71:64:4c:65:2e:81:68:45:a7 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 10:72:52:a9:05:14:19:32:08:41:f0:c5:6b:0a:cc:7e:0f:21: 19:cd:e4:67:dc:5f:a9:1b:e6:ca:e8:73:9d:22:d8:98:6e:73: 03:61:91:c5:7c:b0:45:40:6e:44:9d:8d:b0:b1:96:74:61:2d: 0d:a9:45:d2:a4:92:2a:d6:9a:75:97:6e:3f:53:fd:45:99:60: 1d:a8:2b:4c:f9:5e:a7:09:d8:75:30:d7:d2:65:60:3d:67:d6: 48:55:75:69:3f:91:f5:48:0b:47:69:22:69:82:96:be:c9:c8: 38:86:4a:7a:2c:73:19:48:69:4e:6b:7c:65:bf:0f:fc:70:ce: 88:90
From the upstream Verisign root certs: $ openssl x509 -noout -text -in 'verisign/VeriSign Root Certificates/Generation 1 (G1) PCAs/Class 3 Public Primary Certification Authority.pem' Certificate: Data: Version: 1 (0x0) Serial Number: 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Validity Not Before: Jan 29 00:00:00 1996 GMT Not After : Aug 2 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c9:5c:59:9e:f2:1b:8a:01:14:b4:10:df:04:40: db:e3:57:af:6a:45:40:8f:84:0c:0b:d1:33:d9:d9: 11:cf:ee:02:58:1f:25:f7:2a:a8:44:05:aa:ec:03: 1f:78:7f:9e:93:b9:9a:00:aa:23:7d:d6:ac:85:a2: 63:45:c7:72:27:cc:f4:4c:c6:75:71:d2:39:ef:4f: 42:f0:75:df:0a:90:c6:8e:20:6f:98:0f:f8:ac:23: 5f:70:29:36:a4:c9:86:e7:b1:9a:20:cb:53:a5:85: e7:3d:be:7d:9a:fe:24:45:33:dc:76:15:ed:0f:a2: 71:64:4c:65:2e:81:68:45:a7 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 10:72:52:a9:05:14:19:32:08:41:f0:c5:6b:0a:cc:7e:0f:21: 19:cd:e4:67:dc:5f:a9:1b:e6:ca:e8:73:9d:22:d8:98:6e:73: 03:61:91:c5:7c:b0:45:40:6e:44:9d:8d:b0:b1:96:74:61:2d: 0d:a9:45:d2:a4:92:2a:d6:9a:75:97:6e:3f:53:fd:45:99:60: 1d:a8:2b:4c:f9:5e:a7:09:d8:75:30:d7:d2:65:60:3d:67:d6: 48:55:75:69:3f:91:f5:48:0b:47:69:22:69:82:96:be:c9:c8: 38:86:4a:7a:2c:73:19:48:69:4e:6b:7c:65:bf:0f:fc:70:ce: 88:90
Here's some more on that certificate, it's been obsolete and resigned for ~3 years https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146 http://www.tbs-certificats.com/FAQ/en/490.html Questions raised: - Why does NSS contain the old md2 Verisign cert? - Why does OpenSSL not like the new sha1 cert?
OpenSSL does work w/ mtgox is the old md2 cert is used: $ openssl s_client -connect mtgox.com:443 -CAfile cert.003.pem CONNECTED(00000003) depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority verify return:1 depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL SGC CA verify return:1 depth=0 1.3.6.1.4.1.311.60.2.1.3 = JP, businessCategory = Private Organization, serialNumber = 0110-01-069784, C = JP, ST = Tokyo, L = Suginami, O = K.K. Tibanne, OU = Terms of use at www.verisign.com/rpa (c)05, CN = mtgox.com verify return:1 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0110-01-069784/C=JP/ST=Tokyo/L=Suginami/O=K.K. Tibanne/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mtgox.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0110-01-069784/C=JP/ST=Tokyo/L=Suginami/O=K.K. Tibanne/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mtgox.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA --- No client certificate CA names sent --- SSL handshake has read 4546 bytes and written 521 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: E2E4EDB5109460181E9B0C7957EE70D33ECE9A345D2EB0CADAC2D577F4742134 Session-ID-ctx: Master-Key: 2EB923D043217A590E185643207B9BF6FFB9EBEA5083EE75209D367091DEAC92E3FEDC669FA0045E7BE96E5B66B01765 Key-Arg : None PSK identity: None PSK identity hint: None Start Time: 1332712676 Timeout : 300 (sec) Verify return code: 0 (ok) ---
I would guess (according to http://www.tbs-certificats.com/FAQ/en/490.html ) that using the new root requires to use a different intermediate certificate. I'll get it upgraded. As for why do NSS still contain the old certificate, I would guess they do not want to break the web, unlike ca-certificates. I'd guess many people are in the same state as mtgox.com using an old intermediate.
I can report that updating to the latest unstable ca-certificates package today helped me resolve the "unknown issuer" problem with curl. Comodo had updated it's stuff during 2014 and latest stable was from 2013.
