Dynamically set TLS/SSL certificate path

[snowman2]

When building wheels for pyproj I have discovered that including curl is not enough. I am having issues using PROJ_NETWORK since the path to the CA bundle can vary depending on the operating system/virtual environment.

Here is the error I am running into:

Cannot open https://cdn.proj.org/ca_nrc_ntv2_0.tif: error setting certificate verify locations:

  CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

One idea I have to ensure that users have an up-to-date CA bundle would be to use the python certifi library. Doing so would require the capability to dynamically set the path to the CA bundle. I attempted to modify the CURL_CA_BUNDLE environment variable and it worked on OSX, but I have not got it working on Linux (yet). It would be nice to be able to scope this so you only set it for the curl used by PROJ.

Curl has this method that can be used to dynamically set the path & type:

• https://curl.haxx.se/libcurl/c/CURLOPT_SSLCERT.html
• https://curl.haxx.se/libcurl/c/CURLOPT_SSLCERTTYPE.html

This is something that will need to be updated in networkfilemanager.cpp. I am thinking adding a method to set this would be useful (const int proj_curl_set_sslcert(const char*cert_path, const char* cert_type)).

Thoughts? Suggestions?

[rouault]

Curl and CA bundle was/is a recurring annoyance in GDAL too.
The GDAL logic (not claiming it is the best one) is at https://github.com/OSGeo/gdal/blob/master/gdal/port/cpl_http.cpp#L1839

[rouault]

One option worth considering too (not ideal, but can help when other options fail) is to offer the possibility to disable certificate checks: https://github.com/OSGeo/gdal/blob/master/gdal/port/cpl_http.cpp#L1797

[snowman2]

I see it uses: https://curl.haxx.se/libcurl/c/CURLOPT_CAINFO.html, that is good to know.

I propose to have PROJ to have this CA Bundle search logic to set CURLOPT_CAINFO:

1. Value set by proj_curl_set_ca_bundle_path
2. Environment variable PROJ_CURL_CA_BUNDLE
3. Environment variable CURL_CA_BUNDLE
4. Environment variable SSL_CERT_FILE

Sound like a good idea?

One option worth considering too (not ideal, but can help when other options fail) is to offer the possibility to disable certificate checks.

I see the PROJ_UNSAFE_SSL environment variable.