Re: Certificates: handling updates, multiple domains?

Hi

On 02/05/2023 21:40, Benoit TELLIER wrote:
> Hello
> 
> Quick answer
> 
> On 03/05/2023 08:25, Wojtek wrote:
>> Hi,
>> quick questions:
>> 1) does James support multiple certificates (so I can provide one for each configured 
>> domain/hostname)?
> No.
> 
> Mail is not a HTTP server. OSI level 7 protocols do NOT cary information allowing to resolve domain 
> (like a hostname in HTTP) upon establishing connection. Only login would cary the email address 
> which domain part would allow resolving this. Needless to say: you MUST have SSL already set up when 
> authenticating... This information just come too late...
> 
> The only solution for IMAP would be to have one distinct port / address per domain: not very 
> practical..
> 
> Note: SMTP + STARTTLS would allow this as there is a first EHLO request sent to request the 
> capabilities hence STARTTLS would 'know' which certificate to use...
> 
> Note: If you are building advanced email services, using JMAP, HTTP backed, would be a natural fit 
> where native HTTP tooling like NGinx would allow configuring this like a charm without headache...

Actually I was thinking about it from the XMPP perspective and didn't have HTTP in mind. XMPP is 
quite relatable here: it both allow direct TLS or STARTTLS. In the latter case it's quite obvious to 
which domain you want to connect thus server can server proper certificate for that particular 
domain. In the former case SNI TLS is used to indicated desired/destination domain.

However, I've been digging a little bit more in IMAP/SMTP and it seems that in mail world 
certificate of the host to which MX record points is used and not the actual mail domain so... this 
question turns out to be moot :-)

>> 2) is it possible to update certificates without restarting (rest endpoint)?
>>
> No. Contributing this might be huge work but welcomed... Please open a JIRA on this...

Created: https://issues.apache.org/jira/browse/JAMES-3906

> Note:
> 
>   -> STARTTLS is known to be less secure than upfront SSL CF https://nostarttls.secvuln.info thus 
> for new services I would advocate anyway to NOT set up STARTTLS endpoints for your users, just SSL...
>   -> If you take STARTLS out then encryption become a transport problem, handled at layer 4 by all 
> common TCP proxies, which themselves would support hot reload. Without any additional DEV in James.

In case of using (Direct)TLS this is quite right, but this is still a problem in case of using k8s 
for example, where the default ingres is nginx, and it only allow https. Nginx itself allows TCP SSL 
termination, but it's not exposed in ingress-nginx (yet, at least).

> Added benefits: SSL not done in Java means you would save your precious CPU ;-)


It has to be processed elsewhere though ;-)

Wojtek