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