Hi guys, so if using lets encrypt certificate, anyone can get access? What about certificates with password? Client need to write correct one to get access? Also additional user/pass layer i think good thing ofc with tls/ssl. Thanks for your hard work. I not developer and all i can help u with just testing and get logs :( sorry about that, i know i am disturbing you pretty much Matt and Benoit too.
чт, 13 февр. 2025 г., 07:57 cryptearth <cryptea...@cryptearth.de.invalid>: > 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 > >
