As freeradius validates the client certificate on an EAP-TLS connection and OCSP
Alan DeKok
aland at deployingradius.com
Tue Apr 11 20:39:12 CEST 2017
On Apr 11, 2017, at 7:03 PM, Miguel Hinojosa <miguel.hinojosa at 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.
More information about the Freeradius-Users
mailing list