Bug report #19331
GDAL/VSICURL certificate errors loading cloud optimized geotiffs over https via data source manager
| Status: | Open | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Data Provider | ||
| Affected QGIS version: | 3.2 | Regression?: | No |
| Operating System: | Windows 10 1803 | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 27159 |
Description
Hey there
While testing the cloud-optimized geotiff support, I ran into problems with files hosted via HTTPS.
It can successfully load and display over HTTP, but not HTTPS. When loading over HTTPS, it gives errors like "CURL error: SSL certificate problem: unable to get local issuer certificate" and "CURL error: SSL certificate problem: self signed certificate in certificate chain" (two different servers/URLs for those errors). I've tried hosting the files on Box, Github, a server at my office and a server I run. All files could be accessed over HTTPS in chrome and firefox as standard downloads. When possible to load over standard HTTP, those files succeed in QGIS, but fail over HTTPS with the above errors.
The full error message that's most common is:
CRITICAL Invalid Layer : GDAL provider Cannot open GDAL dataset /vsicurl/https://raw.githubusercontent.com/ucd-cws/nitrates-cv/master/1945/Nharvest_actual.tif:
CURL error: SSL certificate problem: unable to get local issuer certificate
Raster layer Provider is not valid (provider: gdal, URI: /vsicurl/https://raw.githubusercontent.com/ucd-cws/nitrates-cv/master/1945/Nharvest_actual.tif
This happens on 3.2.0 on Windows 10 1803. When using Gdal 2.2.3 on Bash on Ubuntu on Windows, I can successfully use gdal_translate on the files over https, so it seems like a QGIS issue or an issue with QGIS specific to my machine - I've not yet been able to get someone else to try on a different machine. One of the files I'm using is here. It works via gdal_translate/VSICURL in Bash on Ubuntu on Windows but not in QGIS: https://github.com/ucd-cws/nitrates-cv/blob/master/1945/Nharvest_actual.tif?raw=true
A URL that allows access via HTTP and HTTPS where the behavior can also be seen to work over HTTP and not HTTPS is http://managedretreat.org/test/NgwDirect.tif
Related issues
History
#1
Updated by Nick S over 6 years ago
From some further testing, looks like it's related to a long-ish standing CURL/GDAL bug on Windows: http://osgeo-org.1560.x6.nabble.com/gdal-dev-libcurl-and-the-certificates-and-Windows-td5322919.html has an overview, but there's discussion of the issue in relation to GDAL here (https://github.com/curl/curl/issues/1538), including how the CURL_CA_BUNDLE environment variable will be deprecated and programs should find the bundle and pass it to curl themselves. It looks like there are some GDAL commits in response to find the bundle, maybe on the system PATH, so it's possible QGIS' copy of GDAL needs configuration (I'm not sure, getting out of my knowledge area here).
In the meantime, if I set the CURL_CA_BUNDLE environment variable to point to an existing curl-ca-bundle.crt (in my case, the one that ships with R 3.4.0), everything works without turning off certificate verification. This solves the problem on my machine, but not the problem with the distribution. I'm not sure what QGIS' role here is, if it'd be possible to ship its own curl-ca-bundle.crt file and configure GDAL, but I'll leave this open both so others can find the solution and in case there's a role for QGIS in making VSICURL work within the application on Windows even if the upstream is broken. Thanks!
#2
Updated by Giovanni Manghi over 5 years ago
- Duplicated by Bug report #20737: Can't open shapefiles from https websites on windows added