1
I can no longer access certain secure sites with any browser
on one of my machines:
> curl -vvv https://order.subway.com/ > /dev/null
* About to connect() to order.subway.com port 443 (#0)
* Trying 205.210.145.54... connected
* Connected to order.subway.com (205.210.145.54) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
but it works fine w/ another machine on the same network (see below).
This started happening when I went to Edit/Preferences/Advanced/Encryption/View Certificates/Authorities in Firefox and did... something, though I don't remember exactly what.
How do I fix this? I've tried many things, including reinstalling then "openssl" and "ca-certificates" packages, and even copying /etc/pki from the working machine to the nonworking, to no avail.
What's the correct/canonical way to update your certs? Or does the problem have nothing to do w/ certs?
Output of curl on working machine:
$ curl -vvv https://order.subway.com/ > /dev/null
* STATE: INIT => CONNECT handle 0x20048280; line 1090 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* Trying 205.210.145.54...
* STATE: CONNECT => WAITCONNECT handle 0x20048280; line 1143 (connection #0)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Connected to order.subway.com (205.210.145.54) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x20048280; line 1240 (connection #0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x20048280; line 1254 (connection #0)
{ [5 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4514 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [262 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / DES-CBC3-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: jurisdictionC=US; jurisdictionST=Connecticut; businessCategory
=Private Organization; serialNumber=0972970; C=US; ST=Connecticut; L=Milford; O=
Franchise World Headquarters, LLC; OU=Info Systems; CN=order.subway.com
* start date: Jun 11 00:00:00 2015 GMT
* expire date: Jun 4 23:59:59 2017 GMT
* subjectAltName: order.subway.com matched
* issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Sym
antec Class 3 EV SSL CA - G3
* SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x20048280; line 1275 (connection #0)
} [5 bytes data]
> GET / HTTP/1.1
> Host: order.subway.com
> User-Agent: curl/7.45.0
> Accept: /
>
* STATE: DO => DO_DONE handle 0x20048280; line 1337 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x20048280; line 1464 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x20048280; line 1474 (connection #0)
{ [5 bytes data]
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Expires: -1
* Server Microsoft-IIS/7.5 is not blacklisted
< Server: Microsoft-IIS/7.5
< Set-Cookie: ASP.NET_SessionId=3ifrpyo3auwuxq3kj0usk2hi; path=/; HttpOnly
< X-Powered-By: ASP.NET
< Date: Wed, 23 Dec 2015 22:17:40 GMT
< Content-Length: 51049
<
{ [6960 bytes data]
* STATE: PERFORM => DONE handle 0x20048280; line 1632 (connection #0)
* Curl_done
100 51049 100 51049 0 0 86734 0 --:--:-- --:--:-- --:--:-- 88167
* Connection #0 to host order.subway.com left intact
EDIT: @Chloe, I tried your suggestion:
> openssl s_client -connect order.subway.com:443 -msg
CONNECTED(00000003)
>>> SSL 2.0 [length 0092], CLIENT-HELLO
01 03 01 00 69 00 00 00 20 00 00 39 00 00 38 00
00 35 00 00 88 00 00 87 00 00 84 00 00 16 00 00
13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 00 2f
00 00 9a 00 00 99 00 00 96 00 00 45 00 00 44 00
00 41 03 00 80 00 00 05 00 00 04 01 00 80 00 00
15 00 00 12 00 00 09 06 00 40 00 00 14 00 00 11
00 00 08 00 00 06 04 00 80 00 00 03 02 00 80 00
00 ff 81 7b 8a 1d a2 8a 91 d5 59 9c 1c 65 dd 5c
52 51 c1 9c 4d 06 33 97 66 bb 03 9d f1 86 96 c2
48 0d
write:errno=104
Googling around shows this is something about a "peer certificate", but I'm not sure exactly what.
You showed a
curl
failure, and then stated you did something with your browser settings. It sounds like something is broken at the network layer, and not the application layer. Or maybe even a firewall setting. Can you ping your router and a site like google.com or subway.com? Also, we don't need to see the exchange from the machine without problems. That tells us nothing and just wastes cycles. – jww – 2015-12-27T06:56:05.887Also see What is NSS error -5961 (PR_CONNECT_RESET_ERROR). You can verify
– jww – 2015-12-27T06:58:26.830ca-bundel.crt
by cat'ing it. It should be 130 or so PEM encoded certificates. PEM is human readable.