[gdal-dev] GDAL, Proj and cacert

[Jeff McKenna]

Thanks for this discussion Paul, I can also add into the chaos that 
Windows Server x64 has known issues with reading environment variables 
(so in my case, for all MS4W x64 deployments, I have MS4W search known 
locations for the bundle, as a workaround for the code that fails to 
find the environment variables in the GDAL/PROJ/MapServer stack). 
Recently MapServer now has a config file where you can set these 
variables, to avoid that problem.  I believe the GDAL/PROJ stack needs 
something like this as well, to avoid the reliance on these system 
environment variables (full disclosure: I need to test if proj.ini 
accepts the cacert bundle as an environment variable, so my above point 
could be wrong, totally).  But I'm often wrong ha.

-jeff


-- 
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/





On 2022-02-11 1:24 p.m., Paul Harwood wrote:
> I have an application that uses GDAL with Proj Networking set on.
> 
> This is a cross platform application. It works on some platforms but on 
> mac (for instance) I get runtime errors like this
> 
> GDAL failure (1) PROJ: Cannot open 
> https://cdn.proj.org/us_nga_egm96_15.tif 
> <https://cdn.proj.org/us_nga_egm96_15.tif>: error setting certificate 
> file: xxx/cacert.pem
> 
> Proj is looking in the wrong place for the cacert file - which is in the 
> proj search path. I would rather avoid using environment 
> variables (complicated). Is there a programmatic way to set the Proj 
> cacert location or a default location?
> 
> currently - the following are set
> 
> 
> Gdal.SetConfigOption("CURL_CA_BUNDLE", Path.Combine(gdalData, 
> "cacert.pem"));
> Osr.SetPROJSearchPath(projData);
> Osr.SetPROJEnableNetwork(true);
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev