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.