OpenSSL Issue When Running Azure Speech to text on docker

Question

OpenSSL Issue When Running Azure Speech to text on docker

Ayush Kumar 0

Hey folks, I'm trying to run speech-to-text using Python on a docker container, but I'm getting an SSL error, I have tried following the steps mentioned here for SSL setup and also installed the required dependencies as mentioned here. However, I'm still getting the below error:

[681645]: 1031ms SPX_TRACE_INFO:  web_socket.cpp:479 Start to open websocket. WebSocket: 0x5c061df0, wsio handle: 0x5c077670
[681645]: 1031ms SPX_TRACE_SCOPE_ENTER:  uws_web_socket.cpp:149 Open
[681645]: 1031ms SPX_TRACE_INFO: AZ_LOG_INFO:  tlsio_openssl.c:2027 create_openssl_instance by TLS_method.
[681645]: 1031ms SPX_TRACE_INFO: AZ_LOG_INFO:  tlsio_openssl.c:1849 load_system_store not implemented on this platform
[681645]: 1031ms SPX_TRACE_INFO: AZ_LOG_INFO:  tlsio_openssl.c:1878 CRL check off, as requested.
[681645]: 1044ms SPX_TRACE_SCOPE_EXIT:  uws_web_socket.cpp:149 Open
[681645]: 1044ms SPX_DBG_TRACE_SCOPE_ENTER:  web_socket.cpp:221 ~CSpxWebSocket
[681645]: 1044ms SPX_DBG_TRACE_SCOPE_EXIT:  web_socket.cpp:221 ~CSpxWebSocket
[681645]: 1044ms SPX_TRACE_SCOPE_ENTER:  uws_web_socket.cpp:36 ~UwsWebSocket
[681645]: 1044ms SPX_TRACE_SCOPE_EXIT:  uws_web_socket.cpp:36 ~UwsWebSocket
[681645]: 1084ms SPX_TRACE_ERROR: AZ_LOG_ERROR:  tlsio_openssl.c:691 error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
[681645]: 1084ms SPX_TRACE_ERROR: AZ_LOG_ERROR:  tlsio_openssl.c:2464 FORCE-Closing tlsio instance.
[681645]: 1085ms SPX_TRACE_SCOPE_ENTER:  uws_web_socket.cpp:247 OnWebSocketOpened
[681645]: 1085ms SPX_TRACE_ERROR:  web_socket.cpp:907 WS open operation failed with result=1(WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED), code=2573[0x00000a0d], time=2024-05-01T07:03:52.3847480Z
[681645]: 1085ms SPX_TRACE_INFO:  usp_connection.cpp:933 TS:55, TransportError: connection:0x5c0bdc00, code=5, string=Connection failed (no connection to the remote host). Internal error: 1. Error details: Failed with error: WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED
wss://eastus.stt.speech.microsoft.com/speech/universal/v2
X-ConnectionId: 7000285474f844fca94407cc91efc962.

I have also added the below properties in my code.

speech_config.set_property_by_name("OPENSSL_CONTINUE_ON_CRL_DOWNLOAD_FAILURE", "true")
    speech_config.set_property_by_name("OPENSSL_DISABLE_CRL_CHECK", "true")

Below is my docker file which I'm running

FROM python:3.11.9-bullseye
COPY . /app
WORKDIR /app
RUN apt-get update
RUN apt-get install build-essential libssl-dev ca-certificates libasound2 wget
ENV SSL_CERT_DIR=/usr/lib/ssl/certs
ENV SSL_CERT_FILE /usr/lib/ssl/certs/ca-certificates.crt
RUN pip install -r requirements.txt
EXPOSE 8080
ENTRYPOINT ["python"]
CMD ["src/app.py"]

Below is the container details:

User's image

Can someone please help?

Rohit Mungi 49,131 Reputation points Microsoft Employee Moderator

2024-05-01T11:24:14.9733333+00:00

@Ayush Kumar I think the error code in your case 2573 is a known issue from reported issues of the SDK. Please see this issue.

The SDK team has proposed an ETA of Q2 2024 in this comment to support the latest SSL version.

For python, you can use the workaround from this issue, but please ensure to use it only in a container setup. Thanks!!
Ayush Kumar 0 Reputation points

2024-05-01T12:01:40.4333333+00:00

@Rohit Mungi The OpenSSL version is 1.1.1w only in the container, which I think is supported by the SDK, I'm able to run the same code on Centos7 with OpenSSL 1.1.1.w configured, However, the issue is coming while running in the container only.

Container Details are:

Debian GNU/Linux 11

OpenSSL 1.1.1w 11 Sep 2023

Python 3.11.9

Also, I tried the workaround you suggested, but still got the same error.

I have checked the connectivity from the container to the same endpoint also and it is there.
Rohit Mungi 49,131 Reputation points Microsoft Employee Moderator

2024-05-02T08:48:56.48+00:00

@Ayush Kumar Ok, if the version is correct and if it works with CentOS then it should work with Debian too. I see a similar issue reported with debian 12 where for one user it worked with downgrading the version and the other by allowing connection on all networks. Do you think the debugging steps mentioned in the issue will help you find the cause in your case?