Surprisingly, it works with an older version of LibreOffice ( version 5.3.7.2 )
This works because older releases used plaintext HTTP.
but not with a more recent one ( version 6.4.2.2 ). I'm using Win 7 on virtualbox
$ ssldump -r /tmp/failure.pcapng
New TCP connection #1: 10.0.2.15(49218) <-> vm171.documentfoundation.org(443)
1 1 0.0509 (0.0509) C>S Handshake
ClientHello
Version 3.3
cipher suites
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
compression methods
NULL
extensions
server_name
host_name: crashreport.libreoffice.org
signature_algorithms
[…]
Seems cipher negotiation fails. We're using the “intermediate” suite suggested by Mozilla ( https://ssl-config.mozilla.org/#server=nginx&version=1.14.2&config=intermediate&openssl=1.1.1d&guideline=5.4 ):
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
Weirdly enough your SSL/TLS library speaks only GCM with ECDSA certificates, not RSA. RC4 is insecure and we removed support from CBC (per Mozilla profile) on March 5; this was done after a 1 month long analysis to ensure it would cause minimal disruption:
Metrics results based on 14 days worth of requests show the old profile is in fact not really required:
3 TLSv1.1 (0.00%)
52 TLSv1 (0.02%)
18793 cleartext (6.25%)
40057 TLSv1.3 (13.31%)
242011 TLSv1.2 (80.42%)
95 insecure (0.03%)
300916 total
So in the course of this 14 days test period, only 95/300916 (0.03%) clients (maybe all yours? :-P) would fail to connect using the new Intermediated profile (removing support for TLS <1.2 and lecacy ciphers).
Given Windows 7 is EOL now I'm unsure it's worth trying to find a workaround; that said since your SSL/TLS library can speak modern modes (GCM) there might be a way to enable it for RSA, not only ECDSA. Maybe the Antivirus is messing around with the SSL handshake? At least Qualys SSL labs claims it should work with Windows 7. (Also clients not able to speak recent enough TLS versions — 1.2 is from 2008 — or modern ciphers will have more and more trouble to browse websites.)
Anyway, keeping support for <12 year old TLS versions and/or legacy ciphers is a security nightmare and given the above metrics I'm tempted to call this wontfix on the infra side.