Screwed up /etc/pki somehow (I think)

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.

barrycarter

Posted 2015-12-23T22:29:30.023

Reputation: 695

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.887

Also see What is NSS error -5961 (PR_CONNECT_RESET_ERROR). You can verify ca-bundel.crt by cat'ing it. It should be 130 or so PEM encoded certificates. PEM is human readable.

– jww – 2015-12-27T06:58:26.830

Answers

0

Try

openssl s_client -connect order.subway.com:443 -msg

to see if that works. Also try resetting your router, turning your wifi off and on, and rebooting your computer. It might be a network problem.

Chloe

Posted 2015-12-23T22:29:30.023

Reputation: 4 502

Done and results added to question. – barrycarter – 2017-01-06T02:25:59.637

It's definitely a network error. It should spit out the entire server certificate details and then wait for input, and typing the wrong thing will then spit out a HTTP error. Does it happen to all HTTPS sites? Did you reset your router/computer? Try your ISP HTTPS site, because it's closer. Try to change your IP address by changing the MAC of your router, then recycling it to get a new IP from your ISP. Maybe Subway (or their CDN) doesn't like your IP? – Chloe – 2017-01-06T02:39:30.317

It only happens on some https sites. It works fine on other machines on the same NAT network (with the same public IP). Since I originally asked the question (over a year ago), I've rebooted the computer several times (and had a couple of power outages), and that doesn't seem to help. I'm migrating to a new machine, so this is less of an issue now. I've spun up several VMs (same public IP) and it works on all of them so I think I just screwed up something on this specific machine (Fedora Core 11) somehow. – barrycarter – 2017-01-06T03:05:51.890