Important: Please read the Qt Code of Conduct -

QtWebEngine: ERR_SSL_PROTOCOL_ERROR on custom Yocto image

  • I am currently not able to visit any HTTPS-based web site from a QML WebEngineView... I obtain an error page reporting:

    This site can't provide a secure connection

    (site-name-here) sent an invalid response


    while on console I have the following error:] handshake failed; returned -1,
    SSL error code 1, net_error -107

    I am working on a custom Yocto (rocko) image, including qt5 and ca-certificates recipes.

    Is there something to configure on the image for allowing QtWebEngine (Chromium) to access the installed certificates?

    How can I check the list of installed certificates available for QtWebEngine (Chromium)?

    Since the error message is quite generic, how can I increase (if possible) the verbosity of the error?

    Is there something else I need to know about this kind of stuff?

  • @Morix-Dev is it possible that you try connecting to that same server in that device with another browser/tool? (i.e. wget/curl) with verbose output enabled to check what's going on there?

  • Thanks @Pablo-J-Rogina for your interest.

    I've tried to cURL from the same device the same server (let's say and it seems to me that everything is working fine:

    root@imx6dl:~# curl -v -o output.html
    * Rebuilt URL to:
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying
    * TCP_NODELAY set
    * Connected to ( port 443 (#0)
      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* found 148 certificates in /etc/ssl/c
    * ALPN, offering http/1.1
    * SSL connection using TLS1.2 / ECDHE_ECDSA_CHACHA20_POLY1305
    *        server certificate verification OK
    *        server certificate status verification SKIPPED
    *        common name: * (matched)
    *        server certificate expiration date OK
    *        server certificate activation date OK
    *        certificate public key: EC/ECDSA
    *        certificate version: #3
    *        subject: C=US,ST=California,L=Mountain View,O=Google LLC,CN=*
    *        start date: Tue, 24 Apr 2018 10:34:31 GMT
    *        expire date: Tue, 17 Jul 2018 09:27:00 GMT
    *        issuer: C=US,O=Google Trust Services,CN=Google Internet Authority G3
    *        compression: NULL
    * ALPN, server accepted to use http/1.1
    > GET / HTTP/1.1
    > Host:
    > User-Agent: curl/7.54.1
    > Accept: */*
    < HTTP/1.1 200 OK
    < Content-Type: text/html; charset=utf-8
    < Strict-Transport-Security: max-age=31536000
    < Expires: Tue, 27 Apr 1971 19:44:06 EST
    < P3P: CP="This is not a P3P policy! See for more info."
    < X-XSS-Protection: 1; mode=block; report=
    < X-Frame-Options: SAMEORIGIN
    < X-Content-Type-Options: nosniff
    < Cache-Control: no-cache
    < Date: Wed, 16 May 2018 06:04:40 GMT
    < Server: YouTube Frontend Proxy
    < Set-Cookie: VISITOR_INFO1_LIVE=ZnHYI40gIu0; path=/;; expires=Mon, 12-Nov-2018 06:04:40 GMT; ht
    < Set-Cookie: YSC=WB62WY8_qvg; path=/;; httponly
    < Set-Cookie: PREF=f1=50000000; path=/;; expires=Mon, 14-Jan-2019 17:57:40 GMT
    < Alt-Svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":4
    43"; ma=2592000; v="43,42,41,39,35"
    < Accept-Ranges: none
    < Vary: Accept-Encoding
    < Transfer-Encoding: chunked
    { [376 bytes data]
    100  472k    0  472k    0     0   380k      0 --:--:--  0:00:01 --:--:--  380k
    * Connection #0 to host left intact

    Trying to WGET instead lead to a generic "Unreacheable network error" (unluckily on that device I only have the BusyBox's WGET and so the verbose mode is not available):

    root@imx6dl:~# wget
    Connecting to (
    wget: error getting response: Network is unreachable

    >>> EDIT (update) <<<

    The problem with WGET was probably due to some limitations in BusyBox's WGET implementation... now I've cooked a new Yocto image including the full WGET and everything is fine with WGET too:

    root@imx6dl:~# wget -v
    --2018-05-16 06:26:57--
    Resolving,,, ...
    Connecting to||:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [text/html]
    Saving to: 'index.html.3'
    index.html.3                 [  <=>                 ] 453.84K   702KB/s    in 0.6s
    2018-05-16 06:26:58 (702 KB/s) - 'index.html.3' saved [464732]

    Any ideas?

  • @Morix-Dev great, you just proved your device is Ok (both connectivity and certificates) so your issue now is focused to QtWebEngine itself.
    Is it possible you can capture and analyze network traffic from/to the device? I'd try capturing traffic made by curl and compare it to traffice made by your Qt app

  • @Pablo-J.-Rogina : I am not able to detect any relevant differences by comparing the network traffic generated by cURL and the one produced by my QtWebEngine-based application...

    Digging down into source code I found that the problem arises in BoringSSL's function ECDSA_do_verify(), in file ecdsa.c: the last call to BN_cmp() returns a value different than zero, and actually variables u1 and sig->r have different values (see picture at

    Any ideas about how to troubleshoot that?

  • I'm actyally having the same issue!
    Are you using yocto rocko with an imx6 module? I've see that if you're trying to load local html pages in the qtwebengine .. it's working. I suppose is due to the version of chromium on which qtwebengine is based.

    Did you succeeded in get it work?

  • I've got the same situation on my iMX6 with Yocto Rocko. Any solution for this issue? Is the same situation on new release Sumo or Thud?