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 -----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
On Feb 11, 2019, at 9:01 AM, Stefan Winter <stefan.winter@restena.lu> 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.
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
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-avail... 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@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.
participants (3)
-
Alan DeKok -
Chaigneau, Nicolas -
Stefan Winter