rlm_rest and certificates - evolution proposal
aland at deployingradius.com
Wed Jan 24 17:30:19 CET 2018
On Jan 24, 2018, at 11:16 AM, Chaigneau, Nicolas <nicolas.chaigneau at capgemini.com> wrote:
> I'd like to discuss module rlm_rest and how it handles certificates.
> I think parameter "ca_file" has a confusing name, and is not adequate for all cases.
It's mainly there for consistency with EAP and RadSec.
> This parameter allows to set curl option "CURLOPT_ISSUERCERT".
> This is a file that contains one single CA, which is the issuer of the certificate provided by the remote server.
> In the past I've struggled with this option as it seemed to behave differently between factory and production.
> The answer was that on production they have a multi-level CA hierarchy, and were using a bundle of certificates, so it did not work (unless the first certificate in the file was the issuer itself).
> IMO what we need is to allow to set curl option "CURLOPT_CAINFO". If this option is not set, curl will try to validate the CA chain using a default location, and it will fail.
> So I'd like to propose the following evolution:
> 1) Keep option "CURLOPT_ISSUERCERT", it's useful. But the parameter "ca_file" is confusing, so it should be renamed. How about "issuer_cert_file" ? (trying to be consistent with curl option name and other FreeRADIUS parameters)
I don't want to break existing configurations. And it's too late to re-name configuration items in v3, unless they're totally broken.
What would be possible is to *add* a configuration for rlm_rest. So that either one or the other can be used, but not both.
> 2) Add support for option "CURLOPT_CAINFO". Maybe a new parameter named "ca_info_file" ?
> 3) Comment this in the rest module configuration example.
Sounds good to me.
> If you agree with this proposal, I can do a patch for 3.0.x.
> In any case, I'd like to hear your opinion on this.
Patches are always welcome.
More information about the Freeradius-Devel