QGIS server failing to connect to WMS server with 'SSL handshake failed'

Question

Using some WMS layers in my project and running into an issue with QGIS server. This is the server I am trying to connect to:

https://serviceswebcarto.mern.gouv.qc.ca/pes/services/Territoire/SDA_WMS/MapServer/WMSServer?REQUEST=GetCapabilities&SERVICE=WMS

Open the capabilities.xml using Chrome on my linux laptop works fine, and checking the SSL certificate for the site confirms it is good.

When openning the project on the same laptop using QGIS desktop app however complains that the SSL certificate can not be verified. I used the ignore and save option to add it to the laptop's qgis-auth.db and now I can open the project without error on my laptop.

I moved the qgis-auth.db over to my linux server (different machine), and have the following in the Apache2 conf file for the site that hosts the project:

FcgidInitialEnv QGIS_AUTH_DB_DIR_PATH "/home/qgis/qgisserverdb/"
FcgidInitialEnv QGIS_AUTH_PASSWORD_FILE "/home/qgis/qgisserverdb/qgis-auth.db"

Using top I confirmed that the qgis server is being run by the www-data user:

PID   USER      PR  NI VIRT    RES    SHR    S  %CPU  %MEM     TIME+ COMMAND 
81999 www-data  20   0 2061228 285112 168604 R   7.0   1.7   0:02.52 qgis_mapserv.fc

I double checked that the www-data user has access to the qgis-auth.db folder and file:

Results of ls -la for /home/qgis/qgisserverdb/qgis-auth.db
drwxr-xr-x 6 root     root     4096  Jul  8  2020 home
drwxr-xr-x 4 www-data www-data 4096  Nov 29  2019 qgis
drwxr-xr-x 2 www-data www-data 4096  Dec 24 13:53 qgisserverdb
-rw-rw-r-- 1 www-data www-data 53248 Dec 24 13:49 qgis-auth.db

However when I try and get the capabilities of my WMS project from the server I get the following errors:

13:46:50 WARNING WMS[81999]: Download of capabilities failed: SSL handshake failed
13:46:51 WARNING WMS[81999]: Download of capabilities failed: SSL handshake failed
13:46:51 WARNING WMS[81999]: Download of capabilities failed: SSL handshake failed
13:46:51 WARNING WMS[81999]: Download of capabilities failed: SSL handshake failed
13:46:51 CRITICAL Server[81999]: Error, Layer(s) Courbes_de_niveau_921c86d3_476a_4f46_948b_3dcad713f768, Regions_Administratives_72c99a66_c2ee_46d2_af22_74f08b24910c, Reseau_Routier_77d348b0_f5c5_42f6_a219_3e9b5b21facc, Reseau_hydrographique_ab6b9196_9238_4ca6_a619_b609291245c5 not valid in project /home/qgis/projects/Cartographie/Carto2.0/FC4X4Q_Master_Carto2.0.qgz
13:46:51 WARNING Server[81999]: <ServerException>Layer(s) not valid</ServerException>

Those offending layers are all hosted on the above mentionned WMS server. All my other layers are being accessed just fine. REmoving these layers for the project allows things to work OK.

I added the site's certificate to my server's ca-certificates and I can access the capabilities.xml using wget on the server, so base OS SSL config seems to be OK now.

wget "https://serviceswebcarto.mern.gouv.qc.ca/pes/services/Territoire/SDA_WMS/MapServer/WMSServer?REQUEST=GetCapabilities&SERVICE=WMS"
--2021-12-25 14:02:24--  https://serviceswebcarto.mern.gouv.qc.ca/pes/services/Territoire/SDA_WMS/MapServer/WMSServer?REQUEST=GetCapabilities&SERVICE=WMS
Resolving serviceswebcarto.mern.gouv.qc.ca (serviceswebcarto.mern.gouv.qc.ca)... 142.41.245.123
Connecting to serviceswebcarto.mern.gouv.qc.ca (serviceswebcarto.mern.gouv.qc.ca)|142.41.245.123|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80104 (78K) [text/xml]
Saving to: ‘WMSServer?REQUEST=GetCapabilities&SERVICE=WMS’

WMSServer?REQUEST=GetCapabilities&SERVICE=WMS   100%[=====================================================================================================>]  78.23K  --.-KB/s    in 0.01s   

2021-12-25 14:02:24 (5.23 MB/s) - ‘WMSServer?REQUEST=GetCapabilities&SERVICE=WMS’ saved [80104/80104]

This was not working before I added in the sites cert.

So as far as I can tell I am doing everything correctly, yet things are not working. This was working last week just fine. The site's SSL certificate is good until April next year, and the root certificate is good until 2030. Thinking the intermediary certificate has expired or something.

What should I try next?

For reference:

  Server OS = Ubuntu 20.04.3 LTS
  Qgis server = 3.22.2
  
  Laptop OS = Manjaro XFCE 21.2.0
  Qgis desktop = 3.22.1 

Answer 1

I think the issue is not anything in your immediate control. In short, the server, serviceswebcarto.mern.gouv.qc.ca, has its SSL certs incorrectly configured and not sending the fullchain certificate.

The reason that no error is presented with some clients, like calling the API from a web browser, or possibly ArcPro (I don't have access to my copy of Pro at the moment) is that they support chain lookups. That is, if presented with an incomplete SSL key chain, they can figure out the rest using trusted Certificate Authorities.

But, a well configured server should present the fullchain certificate: the issued, intermediate(s), and root certificates.

Using the openssl utility in Linux, this seems to support my suspicions.

---

Calling against the target server.

Command: openssl s_client -connect serviceswebcarto.mern.gouv.qc.ca:443 --debug

Returns:

---
Certificate chain
 0 s:C = CA, ST = Quebec, L = Quebec, O = Gouvernement du Quebec, CN = *.mern.gouv.qc.ca
   i:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
---

My interpretation of this is that it is only presenting the issued certificate, not the intermediate or the root certificates.

---

Calling gis.SE for example.

Command: openssl s_client -connect gis.stackexchange.com:443 --debug

Returns:

---
Certificate chain
 0 s:CN = *.stackexchange.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

This one appears to present, the issued, intermediate, and root certificate. And this 'chain' of identities seem to hold true for the handful of sites I tried. They present multiple identities down to the root certificate.

---

Take all this with a grain of salt, this isn't my expertise, but to me it looks misconfigured.

It is generally best not to make exception for certificates, but if you need it and trust server owners, you can make an exception. It wouldn't be a terrible to write a polite email to the sysadmin and ask if their certs are in order.