rlm_rest in 3.0.17: cert validation of HTTPS server not working

classic Classic list List threaded Threaded
4 messages Options
| Threaded
Open this post in threaded view
|

rlm_rest in 3.0.17: cert validation of HTTPS server not working

Stefan Winter-4
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

-----BEGIN CERTIFICATE-----
MIIDtzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkqhkiG9w0BAQUFADBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv
b3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQG
EwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNl
cnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7c
JpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWxKISKityfCgyDF3qPkKyK53lTXDGEKvYP
mDI2dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNISW1/5WBg1vEfNoTb5a3/UsDg+
wRvDjDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r/wty2p5g0I6QNcZ4
VYcgoc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1roV9Iq4/
AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMB
AAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW
BBRF66Kv9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYun
pyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbYMuRC
dWKuh+vy1dneVrOfzM4UKLkNl2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTf
fwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll74fg38FnSbNd67IJKusm7Xi+fT8r87cm
NW1fiQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64EtlOtCt/qMHt1i8b5QZ7dsvfPx
H2sMNgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwzZr8TDRRu838fYxAe
+o0bJW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw8g==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE+zCCA+OgAwIBAgIQCHC8xa8/25Wakctq7u/kZTANBgkqhkiG9w0BAQsFADBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv
b3QgQ0EwHhcNMTQxMTE4MTIwMDAwWhcNMjQxMTE4MTIwMDAwWjBkMQswCQYDVQQG
EwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFt
MQ8wDQYDVQQKEwZURVJFTkExGDAWBgNVBAMTD1RFUkVOQSBTU0wgQ0EgMzCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMV2Dw/ZQyk7bG3RR63eEL8jwnio
Snc18SNb4EweQefCMQC9iDdFdd25AhCAHo/tZCMERaegOTuBTc9jP8JJ/yKeiLDS
lrlcinQfkioq8hLIt2hUtVhBgUBoBhpPhSn7tU08D08/QJYbzqjMXjX/ZJj1dd10
VAWgNhEEEiRVY++Udy538RV27tOkWUUhn6i+0SftCuirOMo/h9Ha8Y+5Cx9E5+Ct
85XCFk3shKM6ktTPxn3mvcsaQE+zVLHzj28NHuO+SaNW5Ae8jafOHbBbV1bRxBz8
mGXRzUYvkZS/RYVJ+G1ShxwCVgEnFqtyLvRx5GG1IKD6JmlqCvGrn223zyUCAwEA
AaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkG
CCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQu
Y29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGln
aUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRw
Oi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3Js
MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVk
SURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxo
dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBRn/YggFCeYxwnS
JRm76VERY3VQYjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkq
hkiG9w0BAQsFAAOCAQEAqSg1esR71tonHqyYzyc2TxEydHTmQN0dzfJodzWvs4xd
xgS/FfQjZ4u5b5cE60adws3J0aSugS7JurHogNAcyTnBVnZZbJx946nw09E02DxJ
WYsamM6/xvLYMDX/6W9doK867mZTrqqMaci+mqege9iCSzMTyAfzd9fzZM2eY/lC
J1OuEDOJcjcV8b73HjWizsMt8tey5gvHacDlH198aZt+ziYaM0TDuncFO7pdP0GJ
+hY77gRuW6xWS++McPJKe1e9GW6LNgdUJi2GCZQfXzer8CM/jyxflp5HcahE3qm5
hS+1NGClXwmgmkMd1L8tRNaN2v11y18WoA5hwnA9Ng==
-----END CERTIFICATE-----

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

signature.asc (849 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

Re: rlm_rest in 3.0.17: cert validation of HTTPS server not working

Alan DeKok-2
On Feb 11, 2019, at 9:01 AM, Stefan Winter <[hidden email]> wrote:
> 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

  That should work, I think.

> [...]
>
> Then I get an error message during FreeRADIUS' cert validation phase:
> ...
> (15) rest: ERROR: Request failed: 83 - Issuer check against peer certificate failed

  That error is from libcurl, which we use to do the whole HTTP thing:

https://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLESSLISSUERERROR

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

https://curl.haxx.se/libcurl/c/CURLOPT_ISSUERCERT.html

  Which says:

>> A specific error code (CURLE_SSL_ISSUER_ERROR) is defined with the option,
>>  which is returned if the setup of the SSL/TLS session has failed due to a mismatch
>> with the issuer of peer certificate (CURLOPT_SSL_VERIFYPEER has to be set
>> too for the check to fail).

  So rlm_rest says "please check issuer certificate", and libcurl says "failed to validate peer".

  Maybe libcurl is expecting the peer cert to be signed by the CA?  And instead it's signed by an intermediary CA?

  Try using the issuing CA instead of the root CA.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: rlm_rest in 3.0.17: cert validation of HTTPS server not working

Stefan Winter-4
Hi,

>   So rlm_rest says "please check issuer certificate", and libcurl says "failed to validate peer".
>
>   Maybe libcurl is expecting the peer cert to be signed by the CA?  And instead it's signed by an intermediary CA?
>
>   Try using the issuing CA instead of the root CA.

Neither root-only, intermediate-only, or both concatenated worked.

But putting the individual CA certs for root and intermediate in two
distinct files in the directory, c_rehash, and then using ca_path
instead of ca_file *did* work.

Thanks!

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

signature.asc (849 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

RE: rlm_rest in 3.0.17: cert validation of HTTPS server not working

Chaigneau, Nicolas
In reply to this post by Stefan Winter-4
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=[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html