Thank you for reply. I changed check-eap-tls before ocsp as bellow raddb/mods-available/eap tls { tls = tls-common virtual_server = check-eap-tls ocsp { enable = yes override_cert_url = yes url = "http://x.x.x.x:2560/ocsp/" } } raddb/sites-enabled/check-eap-tls if ("%{TLS-Client-Cert-Common-Name}" =~ /^.*@domain\.com$/) { update config { &Auth-Type := Accept } } but in this case ocsp never execute if check-eap-tls success. any ideas? On 2016/04/22 17:03, A.L.M.Buxey@lboro.ac.uk wrote:

Hi,

...

Is it possible to execute check-eap-tls before checking ocsp? and Is it possible to skip ocsp checking if check-eap-tls fail?

have you changed the order in the config? the server works by config order......

alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Thank you for reply. I have to protect cert ddos attacks for OCSP server. I'll find another way. Thanks anyway! On 2016/04/22 22:14, Alan DeKok wrote:

On Apr 22, 2016, at 4:38 AM, Mitsuhiro Nakamura <mitsuhiro.nakamura@nabiq.co.jp> wrote:

...

Thank you for reply. I changed check-eap-tls before ocsp as bellow

Order in the configuration files doesn't matter.

Order *does* matter for "unlang", e.g. in authorize, authenticate, etc.

...

raddb/sites-enabled/check-eap-tls if ("%{TLS-Client-Cert-Common-Name}" =~ /^.*@domain\.com$/) { update config { &Auth-Type := Accept

You cannot do that.

For one, it's "update control", not "update config".

And you *cannot* just return "Accept" for EAP-TLS. The protocol is designed to make that impossible.

i.e. the configuration file lets you do that, but the client will detect that the protocol is wrong, and stop doing EAP-TLS... and not get on the network.

...

but in this case ocsp never execute if check-eap-tls success. any ideas?

If you bypass all of EAP-TLS by forcing Access-Accept, then yes... the EAP-TLS checks will not be run.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Apr 23, 2016, at 8:51 AM, Alan DeKok <aland@deployingradius.com> wrote:

On Apr 23, 2016, at 6:24 AM, Mitsuhiro Nakamura <mitsuhiro.nakamura@nabiq.co.jp> wrote:

...

I have to protect cert ddos attacks for OCSP server.

The solution is to limit the number of EAP authentications which can be done.

And to be honest, EAP takes more work than OCSP checks. If your OCSP server can't keep up with EAP traffic, you need to upgrade your OCSP server.

Well, yes and no. We support OCSP status caching in v3.1.x because OCSP servers are not necessarily built with performance in mind, and calling out to an external entity adds additional latency. There's enough crappy commercial OCSP servers out there that it's a useful feature. -Arran

On Apr 25, 2016, at 9:17 AM, Mitsuhiro Nakamura <mitsuhiro.nakamura@nabiq.co.jp> wrote:

Thanks Mr.Arran

I try to read code.

src/main/tls/ocsp.c in the v3.1.x branch. There's also an example in sites-available/tls-cache.

I was a C programmer.

I'm old but not obsolete!!

C programmers never will be -Arran