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.
I started looking at the code and was thinking on how to modify
#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`
ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_SSL, (void *)&ssl );
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.