On 17.5.2016 10.40, Jan Tomasek wrote: >> Authority Information Access: >> OCSP - URI:http://ocsp.int-x1.letsencrypt.org/ >> CA Issuers - URI:http://cert.int-x1.letsencrypt.org/ > > I've found discusion from 2012 [1] and main reason is no longer true. > Net::SSLeay do support OCSP today [2] > > For EAP-TLS OCSP delay might be issue but for RadSec connection not, I > think. Please can you reconsider adding OCSP support?
Hello Jan, thanks for getting back to OCSP support. As an update, we have preliminary code for doing OCSP lookups during certificate. This can be used to build basic OCSP lookup support in RadSec. After looking at Let's Encrypt and how OCSP is used with Let's Encrypt certificates in more detail, it appears OCSP stapling, or more officially Certificate Status extension defined in RFC 6066, might be something that RadSec could benefit from. However, it looks like server side support needs more bindings in Net::SSLeay so server side OCSP will take longer to implement. Net::SSLeay seems to have the necessary bindings for client side support, so if that could be made available first, if it is useful by itself without the server side OCSP stapling support. I will get back to this once there's working code. Thanks, Heikki -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
