> Am 14.08.2019 um 03:03 schrieb Chris Punches <punches.ch...@gmail.com>:
>
> Wouldnt this be a certbot issue?
It is a certbot issue. They are asking us for help in understanding why the
server behaves this way.
- Stefan
> On Tue, Aug 13, 2019, 17:50 Brad Warren <b...@eff.org> wrote:
> Hi,
>
> I work at the Electronic Frontier Foundation on Certbot where we’re having a
> problem with httpd’s TLS support and it was recommended to me to post the
> issue to this mailing list. Any additional information about this problem
> such as whether or not this a known issue, versions of Apache (or its
> dependencies) that are affected, workarounds, etc. would be greatly
> appreciated.
>
> Last week, we did a release of Certbot which had it configure httpd to
> include a configuration file setting “SSLSessionTickets off” in each HTTPS
> virtual host managed by Certbot. Unfortunately, the addition of this
> directive caused errors during the TLS handshake in some clients (including
> Chrome and Firefox) for some of our users. Some of the users affected by this
> problem were running:
>
> * 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
>
> 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
