rlm_rest and certificates - evolution proposal

[Chaigneau, Nicolas]

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


Yes, it was for me until recently. I spent some time figuring out what was happening. Fortunately in the end I was allowed to do tests on the production server, which helped a lot. :)


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


I was unsure whether it was better to keep a possibly confusing name, or break existing configurations. I have my answer :)
So no renaming, I'll just add some comments then.


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


Will do.
Thanks for your feedback!


Regards,
Nicolas.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.