Schannel: failed to receive handshake, need more data

#1

My domain is: yuk1.jp

I ran this command:

$ curl -v https://yuk1.jp

It produced this output:

  • Rebuilt URL to: https://yuk1.jp/
  • Trying 52.194.2.128…
  • TCP_NODELAY set
  • Connected to yuk1.jp (52.194.2.128) port 443 (#0)
  • schannel: SSL/TLS connection with yuk1.jp 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 yuk1.jp port 443 (step 2/3)
  • schannel: failed to receive handshake, need more data
  • schannel: SSL/TLS connection with yuk1.jp 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 yuk1.jp 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 yuk1.jp 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.

My web server is (include version):

$ sudo httpd -v

Server version: Apache/2.4.39 (Amazon)
Server built: Apr 5 2019 18:55:17

The operating system my web server runs on is (include version):

$ cat /etc/system-release

Amazon Linux AMI release 2018.03

I can login to a root shell on my machine (yes or no, or I don’t know): yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): sudo certbot-auto --version

certbot 0.37.0

I tested SSL at the following site.
https://www.ssllabs.com/ssltest/analyze.html?d=yuk1.jp

SSL will be fine.
But HTTP status code is Request failed.

There seems to be a problem with the handshake.

no problem with HTTP.

Note: Connection was possible until last week.
If checked today, connection is not possible.

thanks

#2

Hi @YuK1

looks like this is a special error - or not really an error.

Checking your domain - https://check-your-website.server-daten.de/?q=yuk1.jp

Domainname Http-Status redirect Sec. G
• http://yuk1.jp/
52.194.2.128 200 0.547 H
• http://www.yuk1.jp/
52.194.2.128 200 0.544 H
• https://yuk1.jp/
52.194.2.128 -10 0.893 P
SecureChannelFailure - The request was aborted: Could not create SSL/TLS secure channel.
• https://www.yuk1.jp/
52.194.2.128 403 4.656 N
Forbidden
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors

https + non-www has a Grade P - no SSL possible. Checking https + www, the certificate is invalid, but the connection works.

Reason of Grade P:

https://yuk1.jp/ 52.194.2.128
-10
Error creating a TLS-Connection: TLSv1.2 and Cipher Suite ECDHE-RSA-AES128-GCM-SHA256 found. This tool uses TLSv1.2, but not that Cipher Suite. Add additional Cipher Suites.

Your server sends a Cipher Suite Windows doesn’t support. So the online tool can’t connect and you can’t connect using curl from Windows.

Checking your url via Curl + Windows 10 - the same problem.

Check your www version and use the list of cipher suites you can find with your non-www version.

1 Like
#3

I fixed it by setting the following to Apache.

SSLSessionTickets on

Thank you for the detailed explanation

3 Likes
#4

Interesting, thanks. Yep, now there is a newer check, Grade H - so both https versions (non-www and www) are working.

1 Like
#5

If you were using Certbot 0.37.0, the default was changed to SSLSessionTickets off. This change was reverted in the 0.37.1 release today.

https://community.letsencrypt.org/search?q=%22session%20tickets%22%20order%3Alatest

3 Likes
#6

Hey @YuK1! Erica from Certbot here. We’re trying to figure out what caused this issue so we can get the feature back in without the errors. It would really help us out if you could email me at erica@eff.org with the following information:

  • the results of the command grep OpenSSL /var/log/httpd/error_log (or elsewhere, if you’ve moved your apache error log location)
  • the contents of your config directory (probably located at /etc/httpd/), redacted as you see fit
  • any changes you’ve made to the config directory in the time since encountering this issue

Thanks!

1 Like
#7

Pinging again @YuK1 – we still haven’t been able to reproduce the issue, and even the Apache developers we’ve talked to don’t understand what’s going on here. Regardless of us making this change again, we’d really like to get to the bottom of this so we can avoid problems like this in the future and can make sure the problem is fixed in whatever software causing a TLS error in this configuration.

If you don’t feel comfortable sending the info I previously mentioned, some other info that might help us is:

  • All mod_ssl directives in the Apache config
  • A high level description of your setup (e.g. are you using PHP/phpmyadmin?)
  • Apache modules loaded

Thanks again!

#8

Thank you all for your help here! We’ve figured this one out, and just put out a release (0.37.2) fixing it in Nginx as well. If you’re interested in the story, you can follow our discussion on GitHub at https://github.com/certbot/certbot/issues/7322.

1 Like
#9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.