Chrome manifests ERR_CONNECTION_CLOSED when trying HTTPS and doesn't gets to fail about SSL certificate

[DiegoJArg]

Hi People,
I am trying to learn more about CouchDB, but I have now 2.5 weeks dealing with SSL certificates and trying to get HTTPS working on a localhost environment.... Why? Because I just wanted to learn how big deal is this to be setup and because a production environment would require it.

PROBLEM:
After enabling SSL accordingly to the manual it doesn't works in Chrome and Safari.

FACTS:

• I can confirm that it enabled https successfully as curl and firefox works after natural complain about unsafe certificate.
• Also IE works inside a parallels desktop environment.
• Chrome manifests with ERR_CONNECTION_CLOSED in both MAC and Windows/Parallels
• Safari manifests that it fails due to it can not establish connection.
• Neither Chrome nor Safari shows the Lock icon or anything related to a bad-certificate.
• Chrome and Safari does works in normal HTTP non-SSL connection.

OTHER DETAILS:

• I looked most of this time searching a problem in the SSL certificate itself and generated a bunch of certificates with different approaches, like becoming a CA at localhost of my own certificate, adding the subjectAltName and stuff... all of them worked in Curl and Firefox, non in Chrome and Safari.

• chrome://flags/#allow-insecure-localhost is ENABLED

• I have seen errors in Chrome that manifests as ERR_SSL_PROTOCOL_ERROR and ERR_CERT_AUTHORITY_INVALID, but ERR_CONNECTION_CLOSED doesn't seem as a Certificate-related problem.

• Running Chrome with debug verbose log enabled doesn't shows the connection handshake ./Google\ Chrome --enable-logging --v=1 at /Library/Application Support/Google/Chrome/chrome_debug.log

• I lost count of how many tests I performed regarding mainly on certificates, but one that I couldn't figure it out is to watch WHEN is the connection interrupted at the handshake itself, as it seems that CouchDB is ending the connection and then ERR_CONNECTION_CLOSED is shown before any certificate is processed and rejected. It also seems that Chrome is not able to show a trace of that handshake as the connection is not-established.

CouchDB 3.1.0
macOS Catalina 10.15.5
Chrome 84.0.4147.89 (Build oficial) (64 bits)
Safari 13.1.1
Firefox 40.0.2
OpenSSL version LibreSSL 2.8.3
curl 7.64.1

¿May this be really about handshaking?
¿May this be an issue at CouchDB side?

[DiegoJArg]

I have tested now downloading CouchDB 2.3.1 for MAC and running it from the downloads folder.

Safari opened up automatically, I changed from HTTP to HTTPS and port to 6984.
It works!
It showed an untrusted certificate warning as expected.

The opened Chrome and the error message changed to ERR_SSL_SERVER_CERT_BAD_FORMAT and "localhost doesn't met security standards".
So is the expected behavior.

Something in CouchDB 3.1.0 does not ssl-handshakes the same as in 2.3.1.

[SinanGabel]

Could it be a SameSite problem?

https://www.chromium.org/updates/same-site/faq

[pasamio]

I had a report of this relating to a third part product I use where CouchDB 3.1 would fail in Safari and the native Mac/iOS app (Tap Forms; I do not represent this product, I'm merely a user of both it and CouchDB) with a certificate error. In the logs from the app, it looked like the Mac was expecting something more and then the connection aborts:

default 07:32:24.290261-0700    Tap Forms   boringssl_session_set_peer_hostname(1154) [C13.1:2][0x12f32e580] SNI 
default 07:32:24.290319-0700    Tap Forms   boringssl_context_set_cipher_suites(843) [C13.1:2][0x12f32e580] Ciphersuite string: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-CHACHA20-POLY1305:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES256-SHA:AES128-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA
default 07:32:24.290380-0700    Tap Forms   nw_protocol_boringssl_begin_connection(497) [C13.1:2][0x12f32e580] early data disabled
default 07:32:24.290463-0700    Tap Forms   boringssl_context_info_handler(1970) [C13.1:2][0x12f32e580] Client handshake started
default 07:32:24.290616-0700    Tap Forms   boringssl_context_message_handler(2258) [C13.1:2][0x12f32e580] Writing SSL3_RT_HANDSHAKE 512 bytes
default 07:32:24.290688-0700    Tap Forms   boringssl_context_info_handler(1983) [C13.1:2][0x12f32e580] Client handshake state: TLS client enter_early_data
default 07:32:24.290751-0700    Tap Forms   boringssl_context_add_handshake_message_pending(578) [C13.1:2][0x12f32e580] Adding message(1)
default 07:32:24.290988-0700    Tap Forms   boringssl_context_info_handler(1983) [C13.1:2][0x12f32e580] Client handshake state: TLS client read_server_hello
default 07:32:24.291090-0700    Tap Forms   boringssl_context_add_handshake_message_pending(578) [C13.1:2][0x12f32e580] Adding message(2)
default 07:32:24.291218-0700    Tap Forms   boringssl_session_handshake_incomplete(170) [C13.1:2][0x12f32e580] Handshake incomplete: waiting for data to read [2]
default 07:32:24.291291-0700    Tap Forms   boringssl_session_handshake_incomplete(170) [C13.1:2][0x12f32e580] Handshake incomplete: waiting for data to read [2]
default 07:32:24.291343-0700    Tap Forms   boringssl_session_handshake_incomplete(170) [C13.1:2][0x12f32e580] Handshake incomplete: waiting for data to read [2]
default 07:32:24.291400-0700    Tap Forms   boringssl_session_handshake_incomplete(170) [C13.1:2][0x12f32e580] Handshake incomplete: waiting for data to read [2]
default 07:32:24.304716-0700    Tap Forms   tcp_input [C13.1:3] flags=[F.] seq=1973295568, ack=107099676, win=2050 state=ESTABLISHED rcv_nxt=1973295568, snd_una=107099676
default 07:32:24.305105-0700    Tap Forms   nw_protocol_tcp_log_summary [C13.1:3] 
    [E5B054B0-884D-426B-B1B7-20A6F68B0D14 :61974<->:6984]
    Init: 1, Conn_Time: 150.826ms, Syn's: 1, WR_T: 0/0, RD_T: 0/0, TFO: 0/0/0, ECN: 0/0/0, TS: 1
    RTT_Cache: kernel, rtt_upd: 2, rtt: 59.375ms, rtt_var: 61.437ms rtt_nc: 132.875ms, rtt_var_nc: 90.500ms
default 07:32:24.305701-0700    Tap Forms   boringssl_session_handshake_incomplete(170) [C13.1:2][0x12f32e580] Handshake incomplete: waiting for data to read [2]
default 07:32:24.305998-0700    Tap Forms   boringssl_session_handshake_incomplete(170) [C13.1:2][0x12f32e580] Handshake incomplete: waiting for data to read [2]
default 07:32:24.306365-0700    Tap Forms   nw_protocol_boringssl_input_finished(1700) [C13.1:2][0x12f32e580] state: 1
default 07:32:24.307473-0700    Tap Forms   nw_protocol_boringssl_error(1677) [C13.1:2][0x12f32e580] Lower protocol stack error during TLS handshake: -9816
default 07:32:24.308407-0700    Tap Forms   nw_flow_disconnected [C13.1 IPv4#fccb2a3a:6984 in_progress channel-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Output protocol disconnected
default 07:32:24.308568-0700    Tap Forms   nw_protocol_boringssl_remove_input_handler(1012) [C13.1:2][0x12f32e580] nw_protocol_boringssl_remove_input_handler forced true
error   07:32:24.309056-0700    Tap Forms   tcp_output [C13.1:3] flags=[R.] seq=107099676, ack=1973295569, win=1029 state=CLOSED rcv_nxt=1973295569, snd_una=107099676
default 07:32:24.309529-0700    Tap Forms   tcp_close [C13.1:3] TCP Packets:

default 07:32:24.309659-0700    Tap Forms   nw_protocol_boringssl_remove_input_handler(1030) [C13.1:2][0x12f32e580] Transferring nw_protocol_boringssl_t handle back into ARC for autorelease
default 07:32:24.313263-0700    Tap Forms   nw_connection_report_state_with_handler_on_nw_queue [C13] reporting state failed error server closed session with no notification
error   07:32:24.313338-0700    Tap Forms   Connection 13: received failure notification
error   07:32:24.313716-0700    Tap Forms   Connection 13: failed to connect 3:-9816, reason -1
error   07:32:24.313795-0700    Tap Forms   Connection 13: encountered error(3:-9816)
default 07:32:24.313869-0700    Tap Forms   Connection 13: is being canceled

Apple's Boring SSL seems to think that there is something missing from the picture. If I try openssl or curl then the server works as CouchDB 3.1. Looking at the packet dump there appears to be an error mentioning "Inappropriate Fallback" after what looks like three "Client Hello" requests. I can share the packet dump because it shows CouchDB 2.3.1 working properly and then after swapping to CouchDB 3.1, the request failing whilst running on the macOS Catalina box.

When testing using Safari, it displayed an error indicating it was unable to connect to the server which seems consistent with the SSL errors in the above log from Tap Forms.

This seems to relate to something in macOS Catalina, and potentially iOS 13, where the certificate requirements were changed. Using CouchDB 3.1 with a macOS Mojave device didn't encounter any issues. The server was setup on a macOS Catalina box.

Tested combinations:

• Certificates were generated and trusted on all devices ahead of testing using a self signed certificate per Apple guidelines.
• A second certificate was generated using a trusted local root CA per Apple guidelines.
• Safari and Tap Forms is used to test on each platform (Mojave, Catalina, iOS). SSL issues were consistent between both applications.
• CouchDB server was running on a macOS Catalina device for all tests.

Client OS	CouchDB Version	Status
macOS Mojave	3.1	✅
macOS Catalina	3.1	❌
macOS Catalina	2.3.1	✅
iOS 13.6.1	3.1	❌
iOS 13.6.1	2.3.1	✅

I have a Ubuntu 20.04 box running CouchDB 3.1 and the Catalina Mac and iOS 13 devices seem to connect to it fine using a certificate generated using the same base script and trusted by those devices using their respective certificate management tools:

#!/bin/bash
# Set abort on error and trace.
set -e
set -x
# Use short hostname and append '.local' to get name
# Change this if you want to use another hostname.
HOSTNAME=$(hostname -s).local
# Delete CouchDB files
rm -rf couchdb*
# Create new key
openssl genrsa -out couchdb.key 2048
# Create new CSR
COUNTRY="Your Country Code e.g. US, CA, DE, etc."
STATE="Your State"
CITY="Your City"
ORGNAME="Your Organization Name"
openssl req -new -key couchdb.key -out couchdb.csr  -subj "/C=$COUNTRY/ST=$STATE/L=$CITY/O=$ORGNAME/CN=$HOSTNAME"
# Create new cert
openssl x509 -req -sha256 -days 735 -in couchdb.csr -out couchdb.crt -signkey couchdb.key -extfile <(printf "extendedKeyUsage = serverAuth \n subjectAltName=DNS:$HOSTNAME \n basicConstraints = CA:TRUE")

[pasamio]

One additional test point, I tried CouchDB 3.1 on Mojave and the Catalina Mac rejected it even with the trusted certificate. The Mojave Mac connecting to the CouchDB 3.1 instance running on itself (with the certificate trusted) worked properly consistent with other testing. It feels like maybe something linked in with the Mac server might be problematic.

[wohali]

Is anyone having this issue in any environment other than macOS?