|Aha. As it happens, I found the answer to my last question already. E.g.
here:
https://github.com/serghey-rodin/vesta/issues/1211 tls_privatekey
= ${if
exists{/usr/local/vesta/data/ssl_pool/${tls_sni}.key}{/usr/local/vesta/data/ssl_pool/${tls_sni}.key}{/usr/local/vesta/ssl/certificate.crt}}
Now the hurdle appears already substantially higher. :-) ... |
vv s/,soes not have/,the exim4 binary does not have/ vv
On 2017-08-18 20:33, Patrick Pfeifer via Exim-users wrote:
> On 2017-08-18 20:12, Jeremy Harris wrote:
>> First, you don't need to copy exim-dev as well as exim-users.
>> Devs will be reading both.
> Ok. Sorry about the noise.
>> Exim does as little work as possible while in a privileged state, and
>> drops privs to do the rest. To regain privs it execs a new Exim.
> Aha. Not in my setup though. (I see only one Exim process with UID
> Debian-exim and I see no way that it could re-gain privs, although
> root-owned, soes not have the suid bit set.)
>> The cert and privatekey files used can depend on information only
>> available immediately before they are needed (such as the remote IP).
>> As such they are only read at that time.
> Aha. Well, that feature is putting some hurdle to the implementation
> of my idea somehow. How is it activated?
>
> Actually /all/ those certificates could / would then just need to be
> read into memory (or a file descriptor to them acquired) early on,
> i.e. as root. I imagine that it the number of keys is reasonably small
> for a typical setup - but I have no clue about such setups actually (?).
>
> Or would that already be too much of a security threat in your eyes as
> well? ... Actually I would argue against it, as with the current setup
> Exim has access to all key files anyway. ...
>
