rlm_rest in 3.0.17: cert validation of HTTPS server not working

[Chaigneau, Nicolas]

Yes, I've stumbled on this also in the past.
I've added some explanations which you can see here:

https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/rest

In short, the file specified by "ca_file" can only contain one certificate. If there are more, they are ignored.
If you want a bundle, you have to use "ca_info_file".


		#  Certificate Authorities:
		#  "ca_file" (libcurl option CURLOPT_ISSUERCERT).
		#    File containing a single CA, which is the issuer of the server
		#    certificate.
		#  "ca_info_file" (libcurl option CURLOPT_CAINFO).
		#    File containing a bundle of certificates, which allow to handle
		#    certificate chain validation.
		#  "ca_path" (libcurl option CURLOPT_CAPATH).
		#    Directory holding CA certificates to verify the peer with.


Regards,
Nicolas.


> -----Message d'origine-----
> De : Freeradius-Users <freeradius-users-bounces+nicolas.chaigneau=capgemini.com at lists.freeradius.org> De la part de Stefan Winter
> Envoyé : lundi 11 février 2019 15:01
> À : FreeRadius users mailing list
> Objet : rlm_rest in 3.0.17: cert validation of HTTPS server not working
> 
> Hello,
> 
> I'm using rlm_rest to validate second-factor tokens to a privacyIDEA server.
> 
> This worked fine with a test env in HTTP, but now doesn't on HTTPS with cert validation enabled.
> 
> I have this on the command-line:
> 
> # openssl s_client -connect 2fa.restena.lu:443 -CAfile /usr/local/freeradius/config/raddb/mods-config/rest/trustroot.pem
> CONNECTED(00000003)
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Assured ID Root CA verify return:1
> depth=1 C = NL, ST = Noord-Holland, L = Amsterdam, O = TERENA, CN = TERENA SSL CA 3 verify return:1
> depth=0 C = LU, L = Esch-sur-Alzette, O = Fondation RESTENA, CN = *.restena.lu verify return:1
> ---
> Certificate chain
>  0 s:/C=LU/L=Esch-sur-Alzette/O=Fondation RESTENA/CN=*.restena.lu
>    i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
>  1 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
>    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
> ---
> [...]
>     Verify return code: 0 (ok)
> 
> I.e. the server sends the intermediate, and the matching root is in the trustroot.pem file.
> 
> But when I transpose this into the rlm_rest config like
> this:
> 
> rest {
>         tls {
>                 ca_file = ${confdir}/mods-config/rest/trustroot.pem
>                 check_cert     = "yes"
> # doesn't work regardless if check_cert_cn is yes or no [...]
> 
> Then I get an error message during FreeRADIUS' cert validation phase:
> 
> rlm_rest (rest): Reserved connection (0)
> (15) rest: Expanding URI components
> (15) rest: EXPAND https://2fa.restena.lu
> (15) rest:    --> https://2fa.restena.lu
> (15) rest: EXPAND //validate/radiuscheck
> (15) rest:    --> //validate/radiuscheck
> (15) rest: Sending HTTP POST to "https://2fa.restena.lu//validate/radiuscheck"
> (15) rest: EXPAND user=%{urlquote:%{User-Name}}&pass=%{urlquote:%{TOTP-Token}}
> (15) rest:    --> user=swinter&pass=thetokenvalue
> (15) rest: ERROR: Request failed: 83 - Issuer check against peer certificate failed
> (15) rest: ERROR: Server returned no data rlm_rest (rest): Released connection (0)
> 
> I don't really know what to make of "Issuer check against peer certificate failed". The root appears to be recognised, and the intermedaite chain is the expected one. So what would be failing here?
> 
> For reference, the two CA certs are pasted at the end. They are the root and intermediate, concatenated. If I only place the root cert itself into the file -> same result.
> 
> Greetings,
> 
> Stefan Winter
>

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.