David Arnold wrote:
Or maybe just check the modification time of the file from time to time and re-initialize if files did change. In Linux you could even set up a file change notification. I think cron detects crontab changes that way (failing on symbolic links).
I'm trying to make OpenLDAP play in concert with SPIFFE workload api.
I figured a frontend overlay would be the right choice if I were to implement the whole of the SPIFFE workload attestation API in it. Maybe that would be a good thing to do, but I'm seriously constrained by my (nonexistent) C skillset, so my options are unfortunately somewhat limited.
On the other hand, different folks might wish to roll their certificates differently without using SPIFFE (will SPIFFE prevail?).
So I think the most useful solution for OpenLDAP users in a general sense would be OpenLDAP to recreate ssl contexts if it detects the current one got expired.
OpenLDAP never actually reads/parses any of the certs you configure, it just passes them directly to the underlying TLS library. So slapd never knows if a cert is expired or not. It sounds like the feature you want (auto-refresh an expired cert) should be implemented in the TLS library itself. Then it will be immediately useful to every app that uses TLS, not just OpenLDAP.
I started looking at the code and was thinking on how to modify https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/t...
#define HAS_TLS( sb ) ber_sockbuf_ctrl( sb, LBER_SB_OPT_HAS_IO, \ (void *)tls_imp->ti_sbio )
It is used to check if a TLS context exists on the socket, and if not creates one.
Modified semantics, that would perfectly cover the use case would check if the socket has a non-expired tls context. If expired, delete it and create it (exactly once and if still expired, bail out with an error) and if non-existent, create it (as currently implemented).
Maybe directly implemented in `ldap_pvt_tls_accept` & `ldap_int_tls_connect`
if ( HAS_TLS( sb )) { ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); } else {
But then I wonder if it's a good idea to reset the context out of tls2.c?
And what's the difference between default tls context and other tls context?
I understand the difference between a server tls and a non-server tls contexts, but how do I tell which is which?
Does such a design make sense? - Note, I'm happy with a works for me patch, but if such thing would grow generally useful and would be accepted, I'd be more than happy.
Best Regards, David A.
On Mon, Aug 24, 2020 at 08:11, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
David Arnold <dar@xoe.solutions <mailto:dar@xoe.solutions>> schrieb am 21.08.2020 um 23:53 in Nachricht<7TOFFQ.C256O3KUUI8O1@xoe.solutions mailto:7TOFFQ.C256O3KUUI8O1@xoe.solutions>: [...]
Furthermore, would this dummy change also reload the certificates that are configured for the syncrepls?If your do not replicate cn=config, then: No. [...]
I'm starting to think plain process signalling for reloading the TLS context would actually be a cleaner, more elegant and stable solution.Or maybe just check the modification time of the file from time to time and re-initialize if files did change. In Linux you could even set up a file change notification. I think cron detects crontab changes that way (failing on symbolic links).
Would you be ok if I opened an issue for that?[...] Regards, Ulrich