prosgarz35 commented on PR #3224: URL: https://github.com/apache/james-project/pull/3224#issuecomment-5951193214
> What is the upside of adding this complexity to James? > There are very nice reverse proxies which also include functionality for ACME or generating the certificates, so it is already possible to access the web API using TLS. > I'm assuming that an attacker can not ready packets on localhost. Having direct .pem support for the Webadmin API actually decreases the operational complexity for system administrators, rather than increasing it. Currently, admins have to manage multiple certificate formats across the same James instance: standard .pem files for mail protocols (IMAP/POP3/SMTP) and Java Keystores (JKS / PKCS12) for Webadmin or JWT. Converting certificates back and forth using openssl and keytool is a notorious pain point, especially when automating renewals with Let's Encrypt / ACME. With the upcoming industry shift toward 45-day certificate lifespans, manual or scripted keystore conversion will become a frequent maintenance burden. Native .pem support allows for a unified "one cert for all" approach across the entire James stack, making certificate rotation clean and seamless without relying on heavy reverse proxy setups. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
