Hello Benoit,

I'm happy to provide something back to the James project. Unfortunately I read your reply too late to start work on it over the past weekend. And currently I work long shifts due to high backlog that has to be cleaned up. I try to tinker some lines together over the upcomming weekend and provide them over on my github.

Long story short: Setting up your own PKI and some lines of Java to setup mutual TLS is quite easy. James already comes with the required BouncyCastle libs bcpkix, bcprov and bcutil to do so. I have to stress: As by the standard any client certificate signed by any of the specified root PKI will pass the verification - so using Let's Encrypt is discouraged as ANY LE client cert will be valid. To use mutual TLS properly one pretty much has to setup thier own PKI to be in control of any certificates issued. Also both Java SSE and BouncyCastle are able to perform basic validity checks like CRL or OCSP but these has to be kept up along. As the RFC only recommends these to have setup but not actually require them the simplest setup is a root ca certificate and two leaf certificates, one for the server and one for the client, without all the fancy stuff like AIA, CRL-dp or any of the other x.509 extensions. This can also be done with a few simple openssl commands (and unless you're a java dev with a jdk installed that's likely the better solution) - but as I'm a hobbyist java dev I always did it this way and don't know the openssl commands. So someone with experience in both my provide a "translation".

Anyway - I see how I have time and report back if I have some example written down.

Have a good one.

Greetings,

Matt

Am 09.02.25 um 22:55 schrieb Benoit TELLIER:
Hi there
I had a private discussion couple of week ago with Jean HELOU who complained of 
webadmin being hard top secure and hé proposer settings up an optional basic 
auth scheme, easier to use that the jwt bearer token.
Would this be helping?
Would this be something you would be willing to contribute, with guidance?
Idem for repairing the TLS setup, or making it usable with pem files...

--

Best regards,

Benoit TELLIER

General manager of Linagora VIETNAM.
Product owner for Team-Mail product.
Chairman of the Apache James project.

Mail: btell...@linagora.com
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)


Le févr. 8, 2025 6:06 PM, de Cryptearth <cryptea...@cryptearth.de.INVALID>Hi 
Ilya,

for me in my very own personal opinion using RSA keys would be fine
already, or any other established public-key auth like SSH. But JWT
already is some sorts of this which just has to be implemented
correctly. I tried to look into it but honestly not really understood
it. So I guess if someone could give me just an example I likely would
be able to figure it out on my own.

Another option I already use on other projects: mutual TLS.
It's easy to setup your own PKI and using client certificates for both
authentication and identification is part of the TLS standard itself and
works with established servers like apache httpd. Implementing it in
java is as easy as to set your own root-ca-cert as trustanchor when
creating the TLS server socket. The server then requests a client
certificate signed by the root-ca-cert (even works with intermediate
certs) during the handshake and if none is presented the connection is
terminated. All the verification is done by the java SSE itself - nothin
complicated to implement - just setup two certificates.

Should this be a (or THE) route to implement security on webadmin? I
don'T think so. It's an open admin control port and no matter if it
comes with some sort of auth or ident it should always be treated as
such - which means: only accessible local and protected by firewall at
the very least. Yes, there still should be some security on top - but it
often comes down to: if an attacker already got local access to your
server in most cases you lost already.

So, TLDR: For me if, for some reason, one need remote access to james
webadmin just use ssh tunneling like

ssh user@host -L8443:localhost:8443

and use the local 8443 and let ssh handle the auth and ident and crypto
and all that stuff. We already have this tool at hand - and: "Don't roll
your own crypto!".


Am 07.02.25 um 10:26 schrieb Ilya Terskov:
yeah guys i tried that in the end but one problem - if i have forwards to
other email - it need to delete also, same for aliases, so if doing script
it need to do all that and recursively.
we sure need 3.9.0 with actions working :) about security on it i think we
need just RSA keys just like used in SSH and ofc encryption on this
chanel no plaintext for sure :)


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org

Reply via email to