felixauringer commented on PR #3224: URL: https://github.com/apache/james-project/pull/3224#issuecomment-5954739021
> 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. I do see the point that using different formats in one code base doesn't make sense. If TLS handling is really necessary in James, I would say that it's enough to support one way of configuring the certificates and would drop the old methods in the web API and only support PEM. That way, the complexity in James would not increase. > With the upcoming industry shift toward 45-day certificate lifespans, manual or scripted keystore conversion will become a frequent maintenance burden. The shift to short-lived certificates encourages automation. Unless you also want to build ACME into James, you need additional software running next to James anyway. Why not let that software also handle the TLS termination so that we do not have to worry about that stuff at all? > Native .pem support allows for a unified "one cert for all" This should not be the goal. I do not think that sharing certificates / keys is a good idea, especially because it's literally no overhead nowadays to get different certificates using ACME. > heavy reverse proxy setups Usually less than 10 lines of configuration. -- 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]
