On Tue, Jan 23, 2018 at 10:05 AM, Aki Tuomi <aki.tuomi@dovecot.fi> wrote:

> On January 23, 2018 at 7:09 PM Arkadiusz Miśkiewicz <arekm@maven.pl> wrote:
>
>
> On Thursday 11 of January 2018, Aki Tuomi wrote:
>
> > Seems we might've made a unexpected change here when we revamped the ssl
> > code.
>
> Revamped, interesting, can it support milions certs now on single machine? (so
> are certs loaded by demand and not wasting memory)
>
> > Aki
>
>
> --
> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Unfortunately not. This time round it was about putting the ssl code mostly in one place, so that we use same code for all SSL connections.



Just to chime in, having some way of supporting SSL certs dynamically would be tremendously useful. Like splitting out the retrieval of certs/key to a socket, that would typically just be a built-in regular dovecot service ("go and get the certs that are configured in dovecot configs"), but could also be a custom unix listener that could return certs/keys. Dovecot would send in the local IP/port and/or SNI name (if there was one) to the socket and then use whatever comes back. A perl/python/etc script doing the unix listener could then grab the appropriate cert/key from wherever (and dovecot would presumably have a time-based cache for certs/keys).  This is just wish-listing :)

Currently, I've got a million different domains on my dovecot boxes, so allowing them all to use per-domain SSL is a bit challenging. I've been searching for an SSL proxy that supports something like nginx/openresty's "ssl_certificate_by_lua_file" (and can communicate the remote IP to dovecot like haproxy does) to put in front of dovecot, to no avail. Having something like that built directly into dovecot would be a dream -- or that can at least farm that functionality out to a custom daemon).