Can we get full mod_ssl configuration info, OpenSSL version and ideally
the associated ssl_error_log output?
Erica from Certbot here -- I wish we could, but I'm having trouble
getting the original reporters to chime in.
We're tracking the issue over on github:
https://github.com/certbot/certbot/issues/7322
That issue has links to the community forum posts where it was
originally reported, along with further debugging steps we've tried.
Original reports:
https://community.letsencrypt.org/t/certificate-renewed-but-site-not-visible/99421
https://community.letsencrypt.org/t/schannel-failed-to-receive-handshake-need-more-data/99400
https://community.letsencrypt.org/t/ssl-error-after-cert-renew/99430
Brad notes that at least two of them are using phpmyadmin, but still
couldn't repro even with that turned on.
Any insights or ideas of what else to try would be appreciated; we want
to turn this feature back on, but don't feel comfortable
doing so without understanding the issue.
Thanks,
Erica
On 2019/08/14 06:46:32, Joe Orton <j...@redhat.com> wrote:
On Tue, Aug 13, 2019 at 02:50:17PM -0700, Brad Warren wrote:>
> * httpd 2.4.18 (from Ubuntu 16.04)>
> * httpd 2.4.25 (from Debian 9)>
> * httpd 2.4.39 (from Amazon Linux 2)>
> >
> They were presumably using the version of OpenSSL available in those
distributions as well although I haven’t been able to verify that yet.>
> >
> The affected clients and their error messages were:>
> >
> * Chrome: ERR_SSL_PROTOCOL_ERROR>
> * Firefox: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET>
> * Wget: OpenSSL: error:1408E0F4:SSL routines:ssl3_get_message:unexpected
message>
I'm not aware of an issue like this, it might be a config which does
not >
get widely tested.>
Trying "SSLSessionTickets off" on Fedora 30 (httpd 2.4.39 + openssl >
1.1.1c) seems to work fine with TLSv1.1 thru v1.3 selected client side
>
(w/same OpenSSL).>
Can we get full mod_ssl configuration info, OpenSSL version and ideally
>
the associated ssl_error_log output?>
Regards, Joe>
> >
> Clients that were reported to be unaffected were:>
> >
> * OpenSSL s_client>
> * Safari>
> >
> Curl was affected for some users, but not others. One report of a failure with
curl provided the output below from which I removed their domain and IP:>
> >
> $ curl -v https://example.com>
> * Rebuilt URL to: https://example.com/>
> * Trying 1.2.3.4...>
> * TCP_NODELAY set >
> * Connected to example.com (1.2.3.4) port 443 (#0)>
> * schannel: SSL/TLS connection with example.com port 443 (step 1/3)>
> * schannel: checking server certificate revocation>
> * schannel: sending initial handshake data: sending 172 bytes...>
> * schannel: sent initial handshake data: sent 172 bytes>
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)>
> * schannel: failed to receive handshake, need more data>
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)>
> * schannel: encrypted data got 2960>
> * schannel: encrypted data buffer: offset 2960 length 4096>
> * schannel: sending next handshake data: sending 126 bytes...>
> * schannel: SSL/TLS connection with example.com port 443 (step 2/3)>
> * schannel: encrypted data got 258 >
> * schannel: encrypted data buffer: offset 258 length 4096>
> * schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
(0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g.
handshake failed). More detail may be available in the Windows System event log.>
> * Closing connection 0>
> * schannel: shutting down SSL/TLS connection with example.com port 443 >
> * schannel: clear security context handle>
> curl: (35) schannel: next InitializeSecurityContext failed:
SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS
alert is received (e.g. handshake failed). More detail may be available in the
Windows System event log.>
> >
> Any ideas about what is going on here? So far we have been unable to even
reproduce the problem.>
> >
> Thanks for any help,>
> Brad Warren>
> Senior Staff Technologist>
> Electronic Frontier Foundation>
