Hello, How feasible would it be to have a ?pluggable? Dovecot setup that would permit arbitrary logic for fetching TLS/SNI certificates and key, rather than having to hard-code each domain?s resources in a configuration file? A couple scenarios that I envision such a framework being able to accommodate: 1) An internal TLS service that accepts queries via a UNIX socket by domain name and returns certificate/key. 2) A directory where these resources are stored, indexed by domain name. Thank you! -FG
On 21 Jun 2016, at 22:58, Felipe Gasper <felipe at felipegasper.com> wrote:> > Hello, > > How feasible would it be to have a ?pluggable? Dovecot setup that would permit arbitrary logic for fetching TLS/SNI certificates and key, rather than having to hard-code each domain?s resources in a configuration file? > > A couple scenarios that I envision such a framework being able to accommodate: > > 1) An internal TLS service that accepts queries via a UNIX socket by domain name and returns certificate/key. > > 2) A directory where these resources are stored, indexed by domain name.Configuration settings are looked up from $base_dir/config socket. In theory you could replace this socket with your own proxy service, which forwards all requests to the real config process and changes the reply in whatever way you want. You should be able to change the default config socket with: service config { unix_listener config { path = config-old } }
> > On 21 Jun 2016, at 5:04 PM, Timo Sirainen <tss at iki.fi> wrote: > > On 21 Jun 2016, at 22:58, Felipe Gasper <felipe at felipegasper.com> wrote: >> >> Hello, >> >> How feasible would it be to have a ?pluggable? Dovecot setup that would permit arbitrary logic for fetching TLS/SNI certificates and key, rather than having to hard-code each domain?s resources in a configuration file? >> >> A couple scenarios that I envision such a framework being able to accommodate: >> >> 1) An internal TLS service that accepts queries via a UNIX socket by domain name and returns certificate/key. >> >> 2) A directory where these resources are stored, indexed by domain name. > > Configuration settings are looked up from $base_dir/config socket. In theory you could replace this socket with your own proxy service, which forwards all requests to the real config process and changes the reply in whatever way you want. You should be able to change the default config socket with: > > service config { > unix_listener config { > path = config-old > } > }Interesting ? thank you! Does this just cache the config at start time, or will it query for each connection? I just tried swapping in my own dummy socket, and it didn?t seem to report anything interesting, which makes me suspect this is a start-time thing. I was hoping for something that could be updated in real-time ? ? Thank you! -FG