rlm_rest and certificates - evolution proposal

[Alan DeKok]

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).

  That's... confusing.

> 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" ?

  Sure.

> 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.

  Alan DeKok.