Re: [ptxdist] [PATCH] libcurl: Added an option set to compile libcurl with optional builtin CA certificate default directory or builtin CA certificate default bundle file.

[Bruno Thomsen <bth@kamstrup.com>]

> > > Any reason, why these paths should be configurable?
> > 
> > /etc/ssl/certs seems to be the most common path to store certificates in.
> > However, we maintain RedHat servers here which use different paths by 
> > default. That's the reason why I made it configurable.
>
> Ok.

I think it's okay to make it configurable.

Ubuntu uses /usr/share/ca-certificates/ so it seems to be very distribution specific.

> > > And we need a package that provides those files, right?
> > 
> > In my opinion, such a package is nothing for the general ptxdist. It 
> > is highly project depending, at least in our company. We do not deploy 
> > a set of default CAs like you have it in the general purpose desktop 
> > or server distributions. For us it is very rare to have two projects 
> > with the same set of CA certificates.

The CA/Browser Forum (CA/B) has adopted new guidelines that deprecate internal server names and reserved IP addresses [1].
After November 1, 2015 certificates for internal names will no longer be trusted.

In other words the public CAs like DigiCert, VeriSign, etc. must only issue certificates to public internet domains with FQDNs.

This will cause an increase of private CAs when devices/servers only communicate on closed networks without internet access.

Inclusion of private CA trust chains is IMHO out of ptxdist scope.

But it's a completely different question if ptxdist should have an option to include a public CA bundle.
There are many use-cases where communication over the internet is useful in embedded devices.
The most obvious is a GSM/UMTS/LTE connected devices, since setting up a customer specific APN with VPN between server hosting and telecommunication company is rather costly.
So the embedded device connect with a standard "internet" APN, and gain NAT'ed internet access, where it can connect to a HTTPS or IPsec server that present a public signed certificate. So the embedded device only needs to be programmed with customer server FQDN and not a customer specific private CA certificate that might not be known at the time of product ordering.

> > Even if we add a certificates package, this should be more related to 
> > the openssl package itself than to the openssl user packages like curl.
> > 
> > Curl runs fine even if the default path (CA path or CA bundle) does 
> > not exist. It is just not finding proper certificates to validate 
> > SSL/TLS connections. This is the same behavior as today, where curl is 
> > configured to not look anywhere for matching certificates.
>
> To create a bundle we would need the script mk-ca-bundle.pl that comes with curl, right?

Yes.

> Bruno, if I apply this patch here, you could change your host-certdata package into a target package that installs the CA bundle itself. Would that make sense to you?

Okay, so I change the host-certdata package to a public-ca-bundle target package in the network section that selects LIBCURL_SSL_CABUNDLE and run the mk-ca-bundle.pl script from curl and install the result into LIBCURL_SSL_CABUNDLE_PATH.

/Bruno

[1] https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf


-- 
ptxdist mailing list
ptxdist@pengutronix.de