EC25 and websocket secure (wss)

I’m trying to connect to a websocket secure server app, designed on NodeJS using my EC25AU module, but I can’t.
Using the following AT commands:

AT+QCFG=“usbnet”,0
AT+QICSGP=1,1,“internet.movil”,“internet”,“internet”,1
AT+QIACT=1
AT+QIACT?
AT+QSSLCFG=“sslversion”,1,1
AT+QSSLCFG=“ciphersuite”,1,0X0035
AT+QSSLCFG=“seclevel”,1,1
AT+QFUPL=“RAM:mycert.pem”,LENGTH_DEL_CERTIFICADO,100

Send complete certificate…
AT+QSSLCFG=“cacert”,2,“RAM:mycert.pem”

AT+QSSLOPEN=2,1,4,“wss://myserver.com”,443,0
AT+QSSLSEND=4

QSSLOPEN return ERROR

QSSLSEND return ERROR

QSSLRECV return ERROR

What am I doing wrong?

Hi Pablo,

You’re running into this issue due to ID mismatches, incorrect server format, and TLS configuration.

You activated PDP context 1, but AT+QSSLOPEN and AT+QSSLCFG use different context IDs.

PDP context ID and SSL context ID must be consistent across all commands.

AT+QSSLOPEN does not accept wss://.

you should write it as “myserver.com

additionally, the SSL is too old. You wrote AT+QSSLCFG=“sslversion”,1,1 // TLS 1.0

Most NodeJS WSS servers require TLS 1.2.

Please use: AT+QSSLCFG=“sslversion”,1,3 // TLS 1.2

AT+QSSLOPEN only opens a TLS socket. It does NOT perform the WebSocket (HTTP Upgrade) handshake.

After a successful QSSLOPEN, you must manually send:

GET / HTTP/1.1
Host: myserver.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key:
Sec-WebSocket-Version: 13

using AT+QSSLSEND.

Recommended working sequence (use context ID = 1)

AT+QICSGP=1,1,“internet.movil”,“internet”,“internet”,1
AT+QIACT=1

AT+QSSLCFG=“sslversion”,1,3
AT+QSSLCFG=“seclevel”,1,1
AT+QSSLCFG=“cacert”,1,“RAM:mycert.pem”

AT+QSSLOPEN=1,1,0,“myserver.com”,443,0

Wait for:

+QSSLOPEN: 0,0

Please give it a try and let me know the result.

Thanks!
Have a great day!

Best Regards,
Ananthan

Well… After much struggle, I’ve managed to open the SSL socket.
Although I’m not yet able to get the welcome message resulting from the handshake with the server.

I tried this header, but it doesn’t work and closes the socket unexpectedly.

GET / HTTP/1.1
Host: myserver.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key:
Sec-WebSocket-Version: 13

It appears that the websocket protocol will need to be manually rewritten.

That’s actually normal and means you’re very close. Even though the SSL socket opens, the WebSocket handshake is being rejected because the header you’re sending isn’t complete.

Sec-WebSocket-Key cannot be empty, the line endings must be proper \r\n with a blank line at the end, and the request path has to match what your NodeJS server is listening on. When any of these are wrong, the server will simply close the connection without replying.

Also, the EC25 only gives you a raw TLS socket, so the WebSocket handshake and all WebSocket framing must be handled manually in your code. Once the handshake is formatted correctly, you should see the server reply with HTTP/1.1 101 Switching Protocols, and only after that will any welcome message arrive.

Regards,
Ananthan

Ok.
I was given a PDF tutorial that uses Postman to obtain the HTTPS header, but…
Will it be necessary to manually obtain this header every time the site’s SSL certificate is updated (which happens approximately every 6 months)?
Is it still necessary to upload the certificate using the AT+QFUPL command?

I can use OTA to transfer the updated certificate to the ESP32 that commands the EC25 module, also upload on this module, but the header problem is much more complicated.

Hi Pablo,

To answer your question, no, you do not need to manually obtain a new HTTPS/WebSocket header every time the server’s SSL certificate is renewed. Certificate renewal happens at the TLS layer, while the WebSocket Upgrade header is part of the HTTP application layer; as long as the domain name, port, and WebSocket path remain unchanged, the same handshake header can be reused.

Is it still necessary to upload the certificate using the AT+QFUPL command?

However, you still need to upload the updated CA certificate to the EC25 using AT+QFUPL if server authentication is enabled (AT+QSSLCFG=“seclevel”,,1), and then associate it with the SSL context using AT+QSSLCFG=“cacert”,,. To simplify things, instead of relying on Postman each time, it’s best to hardcode a standard WebSocket handshake template in your ESP32 firmware and simply generate or reuse a valid Sec-WebSocket-Key. This way, certificate updates can be handled via OTA without complicating the WebSocket header process.

Hope this helps!

Thanks!
Have a great day!

Best Regards,
Ananthan