Webadmin api pem

[prosgarz35]

follow up for full .pem cert mechanics

#3223

[chibenwa]

(can't wait for a Java version with native SSL support)

Thanks for this contribution!

No objectiosn on my side. Let's pass the build

[prosgarz35]

(can't wait for a Java version with native SSL support)

Thanks for this contribution!

No objectiosn on my side. Let's pass the build

i am testing why build fails but yeah one cert for all for surely better than pain in ass for anyone who making certs (especialy when in 2027-28 they become 47-48 days ye?)

[prosgarz35]

I dont know why it faild to build, help me please dear @chibenwa

[quantranhong1999]

I just trigger a new build FYI.

[prosgarz35]

I just trigger a new build FYI.

Thanks alot, why it is happening? I see errors and its nothing to my code don't it?

[prosgarz35]

Looking at the provided build log, there are no errors or build failures recorded in this snippet.
Here is what took place up to this point:

• The pipeline initialized the environment, cleaned the workspace, fetched the branches, and merged cleanly (PR-3224 into master).
• Early reactor phases completed successfully: plugins were resolved, and the initial modules (james-project, examples) passed their enforce, checkstyle, and sortpom verifications before installing.
• Parallel execution kicked off across 24 threads (-T1C). The only log entries flagged were informational Maven warnings noting that maven-surefire-report-plugin:3.5.3 is not marked as thread-safe for parallel builds, which is standard behavior and non-fatal.
  The log simply cuts off mid-execution as the next set of modules (james-server, event-sourcing, testing-base, etc.) started processing

[felixauringer]

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 read packets on localhost.

[prosgarz35]

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.

[felixauringer]

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.

[prosgarz35]

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.

If you ask me i am personaly also dont see point have oldschool java keystores but that not me who choose remove it or not. About acme into james well i think its good because james complete mail server suit? Then without certificates its not completed because some external mail server just dont even receive you mail in terms of anti bot defense. Acme library i see in some projects but this i think too much for one PR.

[chibenwa]

James uses PEM or keystore for IMAP/SSL set up
Choice for JMAP was not to handle PEN ourselves but rely on a reverse proxy to do it.
Webadmin doing SSL is a legacy decision.
I see 2 direction:

• Either we decide that SSL support for HTTP must be built in, and so we need to allign on PEM support and add SSL support for JMAP
• Or we decide that one should rely eg on NGINX and thus we deprecate SSL support for webadmin.
  I have personnally not really an opinion on the 2 to be honnest.
  I thing it could be a good topic to be raised on server-dev@james.apache.org.
  Good weekend, all!
  Benoit

[felixauringer]

About acme into james well i think its good because james complete mail server suit?

For me, a software can be complete without doing everything on its own. James also uses software specialized on data storage, so why not also use software specialized on certificate management and TLS?

Acme library i see in some projects but this i think too much for one PR.

I'd say that ACME support for James is generally too much, not only for one PR but in general.

[chibenwa]

We need to do a better job here:

• Reject specifying both keystore and pem as otherwize the behaviour is ambiguous
• Reject half configured PEM. An explicit error on what is missing is way better then a silent http downgrade.

[chibenwa]

Hello @prosgarz35
Given this is implemented I'd agree to merge it.
Objections @felixauringer ?
Cheers,
Benoit

[felixauringer]

Hello @prosgarz35 Given this is implemented I'd agree to merge it. Objections @felixauringer ? Cheers, Benoit

As said on the mailing list, I am not necessarily in favor of handling TLS here because you have to run an ACME client externally anyway. However, I'm fine with this if we drop the keystore support in the future and continue with only X509.

@prosgarz35 I do not really like the wording PEM certificate. In my opinion, the type of certificate (X.509) is at least as relevant as its encoding. So what we require in the configuration is not a PEM certificate but a PEM-encoded X.509 certificate.
I'm okay with leaving it as it is but maybe for future work on cryptography related stuff: Be precise what exactly you mean. It makes a very bad impression for other people to use outdated / misleading terminology (like SSL, PEM certificate, ...).

[chibenwa]

It makes a very bad impression for other people to use outdated / misleading terminology (like SSL, PEM certificate, ...).

I'm presume I'm the one to blame for this. I propose we add exact mentions in the doc, but I would be a bit more reluctant to have config changes (retro-compatibility...)