> On November 11, 2016 at 12:22 PM Arkadiusz Miśkiewicz <ar...@maven.pl> wrote:
>
>
> On Friday 11 of November 2016, Felipe Gasper wrote:
> > Hello,
> >
> > We’re rolling out large SNI deployments for our mail servers. Each
> > domain
> > gets an entry like this in the config:
> >
> > local_name mail.foo.com {
> > ssl_cert = </ssl/domain_tls/*.foo.com/combined
> > ssl_key = </ssl/domain_tls/*.foo.com/combined
> > }
>
> Lack of glob/regexp support here is also a problem (for me). I could have 50%
> smaller config if local_name supported regexp matching, so it would be
> possible to do:
>
> local_name ^(pop3|imap)\.foo\.com {
> ...
> }
>
> or even with glob like *.foo.com matching.
>
> >
> > There are a couple problems we’re finding with this approach:
> >
> > 1) Dovecot wants to load everything at once, which has some machines taking
> > up many GiB of memory just for Dovecot. Is there any way to defer loading
> > of an SSL cert until a client actually requests it?
>
> No - thread here http://www.dovecot.org/list/dovecot/2016-October/105855.html
>
> Memory is one thing.
>
> The other is that dovecot stops accepting clients when huge config reload
> happens (I guess it's a design problem since it makes no sense to do that in
> any case. Clients should be processed without gap using old config until new
> config is loaded and ready to go).
>
> And third problem is that there is hardcoded 10s limit for reloading which in
> case thousands of certificates is way too short limit. Anyway if you hit that
> limit it's already lost case due to earlier problem.
>
> >
> > 2) Any time we add or remove a domain, Dovecot’s SNI config matrix needs to
> > be rebuilt. Is there a way to handle SNI requests dynamically via some
> > sort of configuration plugin, so we wouldn’t need to rebuild the config on
> > domain add/remove? I looked through the docs but couldn’t see a way to do
> > this.
>
> That's unavoidable for now :-(
>
> Here we started analyzing maillog and put into dovecot config only these ssl
> certs for domains that are actually used with TLS. It's very ugly and short-
> sighted approach but hopefuly proper solution will be implemented by dovecot
> team before all people start to use TLS.
>
> > Thank you in advance!
> >
> > -Felipe Gasper
> > Mississauga, ON
>
>
> --
> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
Hi!
We are going to do some changes at some point how the certs are loaded and
handled to alleviate this. The idea is not yet ripe, so I won't go into too
much detail, but idea is to move the cert storage from protocol login processes
to elsewhere.
The local_name matching can probably be fixed faster, it could use the same
rules as matching cert names generally do.
Aki
