Failed SSL Connection - ERROR: "[HTTPS:E] SSL_accept failed. Aborting handshake. FID=55"

[jaygitdev]

Describe the bug Receiving the following error when opening the IP address specified in the the Self-Signed_Certificate example:

16:38:10.846 -> [HTTPS:I] New connection. Socket FID=55 16:38:12.065 -> [HTTPS:E] SSL_accept failed. Aborting handshake. FID=55 16:38:12.065 -> [HTTPS:I] Connection closed. Socket FID=55

How To Reproduce Steps to reproduce the behavior:

1. Open Self-Signed_Certificate example
2. Change SSID and password for Wifi
3. Compile Self_Signed_Certificate example
4. Upload Code onto ESP32 (I'm using the ESP32S2)
5. Open browser and navigate to specified IP address (taken from Tools->Serial Monitor)

Expected Behavior I was expecting to be able to securely connect to the ESP32 in the browser

Actual Behavior Both Chrome and Internet Explorer wouldn't open the page. Firefox gave the warning error:

16:38:10.846 -> [HTTPS:I] New connection. Socket FID=55 16:38:12.065 -> [HTTPS:E] SSL_accept failed. Aborting handshake. FID=55 16:38:12.065 -> [HTTPS:I] Connection closed. Socket FID=55

ESP32 Module Please provide specifications of your module

• ESP32-S2 SAOLA-1
• RAM/PSRAM: 320 KB of RAM/Disabled PSRAM
• Flash Size: 4MB with SPIFFS (1.2MB APP/1.5MB SPIFFS)
• Other special properties: NA

Software (please complete the following information if applicable)

• IDE and Version: Arduino 1.8.15
• OS: Windows 10
• Client used to access the server: Firefox, Chrome, Internet Explorer (see actual behavior section for details)

Additional context NA

[Frtrillo]

Having same issue with exampley certs

[ThomasRiddle]

Same issue here. I use Safari to access the server.

[Dilbert66]

Can you try modifying file httpsserver.cpp line 66 to use TLS_server_method() instead of TLSv1_2_server_method() to see if that helps. TLSv1_2 restricts you to only that method and is deprecated.

uint8_t HTTPSServer::setupSSLCTX() {
  //_sslctx = SSL_CTX_new(TLSv1_2_server_method());
 _sslctx = SSL_CTX_new(TLS_server_method());  

I have no issues using either in Chrome or Edge browsers so not sure what the problem on your end is.

[jcassel]

Same issue and tried above possible solve by @Dilbert66 with no change. Using Chrome and Edge on Win 10 Pro.

[JKuzniar57]

Same issue, Chrome/Edge, self signed cert example. Pity, this could be a good package.

[petoknm]

Also hitting this issue now, and it used to work several days ago... I upgraded my platform (ESP-IDF and config), could that have affected it?

[Dilbert66]

The issue is more likely related to the upstream Espressif openssl-api library itself which uses mbedtls and not with this esp32_https_server library. Looks like Expressif is discontinuing it's support for it and asking devs to use esp-tls instead. The esp32_https_server lib would need to be rewritten for that.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/openssl_apis.html#

[JKuzniar57]

Dilbert66, yes that must be it. Unfortunate. I do not have the expertise to rewrite. bummer.

[BlueAndi]

The SSL_accept() returns the error here: https://github.com/fhessel/esp32_https_server/blob/de1876cf6fe717cf236ad6603a97e88f22e38d62/src/HTTPSConnection.cpp#L41

SSL_get_error() returns a SSL_ERROR_SYSCALL:

Some non-recoverable, fatal I/O error occurred. The OpenSSL error queue may contain more information on the error. For socket I/O on Unix systems, consult errno for details. If this error occurs then no further I/O operations should be performed on the connection and SSL_shutdown() must not be called.

This value can also be returned for other errors, check the error queue for details.

errno returns: EAGAIN

#define EAGAIN 11 /* No more processes */

Root cause not clear right now.

[isaacgr]

Seeing this as well. Any other possible workarounds/solutions?

[BlueAndi]

Not yet. Fixed further problems, see: https://github.com/NewTec-GmbH/esp32_https_server/commit/88091b6f621c74977f7597d596b02a6975c739f0

And we created some wireshark traces. @gabryelreyes Can you add the wireshark trace result here?

[isaacgr]

So I think I got it working. It still reports those errors, and they spam for a bit while loading the webpage, but eventually it loads with https.

I just followed the workaround mentioned in #147 to load the certs from file and it appears to be working.

[BlueAndi]

It works for us without #147 as well, similar like in your logs. But the problem still exists and causes a slow connection.

[gabryelreyes]

This is the Wireshark Trace of one of the "SSL_Accept failed. Aborting handshake" messages. It is a really "standard" failed SSL, failed in phase 2 (https://www.geeksforgeeks.org/secure-socket-layer-ssl/) after the server sends the certificate

Edit: Forgot to specify. 192.168.4.1 is the ESP32, and 192.168.4.2 is the client (Chrome)

[gabryelreyes]

After the initial SSL fail, the next request goes through, the client accepts the certificate, and the connection goes as intended, however really slow.

After this successful connection, there is at least 30 client requests that get cut because of the SSL failure, which looks exactly as the image in the comment above. This can also be seen in the Serial Logs as a large number of consecutive messages:

[HTTPS:I:     15163] New connection. Socket FID=49
[HTTPS:E:     15814] SSL_accept failed. Aborting handshake. FID=49
[HTTPS:I:     15816] Connection closed. Socket FID=49