On Wed, Jul 12, 2017 at 04:53:03PM -0500, David Graziano wrote: > I have a project that is using hostapd with its integrated eap_server > with EAP-TLS authentication. I’m running into an issue with the > check_crl feature. When the crl expires it rejects all eap-tls > authentication attempts with a “TLS: Certificate verification failed, > error 12 (CRL has expired) depth 0” error. I have a use > case/requirement that I need to continue allowing clients to > authenticate even if the CRL has expired as I won’t always have the > ability to download a new CRL with the current one expires. Are you in control of generating the CRL? If so and if it is not used for other purposes, I'd simply increase the lifetime of each CRL to be sufficiently long to avoid this.. Expired CRL is expected to reject authentication, so the behavior here in eap_server looks quite reasonable. > Strongswan, for example, has a “strictcrlpolicy” option that makes it > tolerant an expired CRL. With this option disabled if the expiration > date defined by the nextUpdate field of a CRL has been reached a > warning is issued, but a peer certificate will still be accepted if it > has not been revoked. > > I’ve looked and an option such as this doesn’t seem to exist for > hostapd. Would the community be willing to consider a patch-set adding > such a feature? I’m thinking of adding a new “check_crl_strict” config > option that defaults to the current behavior but when set to 0 ignores > the openssl error codes related to CRL validation dates. Or possibly > add more options to the “check_crl” config option such that when set > to 3 or 4 it behaves the same as 1 and 2 respectively but ignores the > CRL validation dates. As long as this is clearly documented and disabled by default, it sounds fine to add such an option. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
