Re: Certificates: handling updates, multiple domains?

Edit.

Please also note that AbstractConfigurableAsyncServer::buildSSLContext 
method can be overwridden if you wishes to experiment with hot reload ;-)

So far this method is called at server initialization, which makes sense 
with an immutable configuration...

Best regards,

Benoit

On 03/05/2023 08: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...
Another way could be to use client certificates: James IMAP stack would 
theorically know which certificate to present for the given client 
certificate.

Downside: significant work on the MUA side. For instance I am not aware 
of Thunderbird supporting client certificate.
>> 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...
>
> 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.
>
> Added benefits: SSL not done in Java means you would save your 
> precious CPU ;-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>