As freeradius validates the client certificate on an EAP-TLS connection and OCSP
We are documenting the architecture and configuration of freeradius 3.0.11 deployed. We need confirmation on two doubts about EAP-TLS connection. After documenting SSL Chain Verification and reviewing the Red Hat Certificate System document, we want you to confirm that we are in the correct assumption. https://access.redhat.com/documentation/en-US/Red_Hat_ Certificate_System/8.0/html/Deployment_Guide/Introduction_ to_Public_Key_Cryptography-Certificates_and_Authentication.html# Certificates_and_Authentication-How_CA_Certificates_Establish_Trust Configuration: - CA del server (/etc/pki/CApath.client) donde tenemos 1x rootCA.pem y 1x issuingCA-1.pem (issued by rootca.pem) - server.pem issued by issuingCA-1.pem - client cert issued by other issuingCA-2.pem (not on local CA of freeradius server) - issuingCA-2.pem issued by same rootCA.pem (same keyid too) --- When the mentioned client with cert-client-issued-by-issuingCA-2.pem try connecting to radius: *Case 1: client sends issuingCA-2.pem certificate during ssl negotiation. Although radius does not have it in your local CA, radius will be able to complete the chain according to the ssl-chain-verification documentation, the client's certificate is signed by issuingCA-2 and signed by rootCA.pem that it does, correct? *Case 2: client does not send the issuingCA-2.pem certificate, it will not be able to complete the chain and should deny the connection, right? --- I understand that the OCSP server, if you send the certificate of the intermediate CA will verify it as it does with the certificate of the client. But when freeradius checks the client's certificate via OCSP, does it verify during the same connection (request) the certificate of the intermediate CA? Or is that done only at the checkpoint of the CRL? == **eap config eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests} tls-config tls-common { private_key_password = private_key_file = ${certdir}/private/server.key certificate_file = ${certdir}/certs/server.pem dh_file = ${certdir}/private/dh ca_path = ${cadir} cipher_list = "DEFAULT" ecdh_curve = "prime256v1" cache { enable = yes max_entries = 255 } verify { skip_if_ocsp_ok = yes tmpdir = /var/tmp/radiusd/verify client = "/usr/bin/openssl verify -CApath ${..ca_path} -crl_check_all %{TLS-Client-Cert-Filename}" } ocsp { enable = yes timeout = 4 softfail = yes } } tls { tls = tls-common virtual_server = check-eap-tls } peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "inner-tunnel" } mschapv2 { } } Thanks Best regards
On Apr 11, 2017, at 4:46 PM, Miguel Hinojosa <miguel.hinojosa@gruposothis.com> wrote:
We are documenting the architecture and configuration of freeradius 3.0.11 deployed. We need confirmation on two doubts about EAP-TLS connection.
Most of these questions are about TLS. EAP-TLS uses the standard TLS protocol and certificates in the standard way. The only difference is that TLS is carried in EAP, instead of TCP.
When the mentioned client with cert-client-issued-by-issuingCA-2.pem try connecting to radius: *Case 1: client sends issuingCA-2.pem certificate during ssl negotiation. Although radius does not have it in your local CA, radius will be able to complete the chain according to the ssl-chain-verification documentation, the client's certificate is signed by issuingCA-2 and signed by rootCA.pem that it does, correct? *Case 2: client does not send the issuingCA-2.pem certificate, it will not be able to complete the chain and should deny the connection, right?
I'd suggest asking RedHat about their documentation. We didn't write it, so we can't help much. If you want to know how EAP-TLS works, the standard is publicly available: https://www.ietf.org/rfc/rfc5216.txt
But when freeradius checks the client's certificate via OCSP, does it verify during the same connection (request) the certificate of the intermediate CA?
The certificate chain is checked. If an intermediate CA fails validation, the end client certificate cannot be validated. This is how TLS works. Alan DeKok.
2017-04-11 18:20 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
When the mentioned client with cert-client-issued-by-issuingCA-2.pem try connecting to radius: *Case 1: client sends issuingCA-2.pem certificate during ssl negotiation. Although radius does not have it in your local CA, radius will be able to complete the chain according to the ssl-chain-verification documentation, the client's certificate is signed by issuingCA-2 and signed by rootCA.pem that it does, correct? *Case 2: client does not send the issuingCA-2.pem certificate, it will not be able to complete the chain and should deny the connection, right?
I'd suggest asking RedHat about their documentation. We didn't write it, so we can't help much.
If you want to know how EAP-TLS works, the standard is publicly available:
Sorry, obviously apart from the Red Hat documentation, the question is: How does radius validate the chain? in rfc5216: Where the EAP-TLS server is unable to retrieve intermediate certificates, either it will need to be pre-configured with the necessary intermediate certificates to complete path validation ***or it will rely on the EAP-TLS peer to provide this information as part of the TLS handshake** So I understand that radius uses the openssl such that (issuingCA-2 providede by client): # openssl verify -untrusted issuingCA-2.pem -CApath /etc/pki/CApath.client cert-client-issued-by-issuingCA-2.pem /peer-cert: OK
But when freeradius checks the client's certificate via OCSP, does it verify during the same connection (request) the certificate of the intermediate CA?
The certificate chain is checked. If an intermediate CA fails validation, the end client certificate cannot be validated. This is how TLS works.
Where does radius determine the revocation status of the intermediateCA? In order to verify the intermediate one would have to make use of this? # check_crl = yes # Check if intermediate CAs have been revoked. # check_all_crl = yes Thanks
On Apr 11, 2017, at 7:03 PM, Miguel Hinojosa <miguel.hinojosa@gruposothis.com> wrote:
Sorry, obviously apart from the Red Hat documentation, the question is: How does radius validate the chain?
By calling OpenSSL, and asking OpenSSL to validate the cert. We don't re-implement TLS. We rely on OpenSSL. Just like most other products. How does OpenSSL validate the cert? By using standard TLS validation methods. Which are basically to walk the certificate chain, and verify the lifetime and signature of each cert. These answers are the simplest and most truthful answers you'll get. They're *not* me being difficult. There's no "FreeRADIUS magic certificate validation". It's all standards based.
in rfc5216: Where the EAP-TLS server is unable to retrieve intermediate certificates, either it will need to be pre-configured with the necessary intermediate certificates to complete path validation ***or it will rely on the EAP-TLS peer to provide this information as part of the TLS handshake**
So I understand that radius uses the openssl such that (issuingCA-2 providede by client): # openssl verify -untrusted issuingCA-2.pem -CApath /etc/pki/CApath.client cert-client-issued-by-issuingCA-2.pem /peer-cert: OK
Yes.
Where does radius determine the revocation status of the intermediateCA?
By asking OpenSSL to do the work.
In order to verify the intermediate one would have to make use of this? # check_crl = yes
# Check if intermediate CAs have been revoked. # check_all_crl = yes
That's what the documentation says. It's telling you the truth. Alan DeKok.
participants (2)
-
Alan DeKok -
Miguel Hinojosa