25 Followers
1 Following
26 Posts

This is the official acme4j channel. You will find release announcements and other acme4j related topics here.

acme4j is an open source Java client for the ACME protocol (RFC 8555). This is an independent project that is not related to or affiliated with Let's Encrypt.

#acme4j #RFC8555 #LetsEncrypt #OSS

Homepagehttps://acme4j.dev
Sourcehttps://codeberg.org/shred/acme4j
Author@shred

#acme4j v5.0.0 is there. It supports dns-persist-01 now (see https://letsencrypt.org/2026/02/18/dns-persist-01.html).

Although it is a major update, it does not break anything unless you use `Login.getKeyPair()` or `Login.getAccountLocation()` in your code.

https://github.com/shred/acme4j/releases/tag/v5.0.0

DNS-PERSIST-01: A New Model for DNS-based Challenge Validation

When you request a certificate from Let’s Encrypt, our servers validate that you control the hostnames in that certificate using ACME challenges. For subscribers who need wildcard certificates or who prefer not to expose infrastructure to the public Internet, the DNS-01 challenge type has long been the only choice. DNS-01 works well. It is widely supported and battle-tested, but it comes with operational costs: DNS propagation delays, recurring DNS updates at renewal time, and automation that often requires distributing DNS credentials throughout your infrastructure.

#acme4j v4.0.0 is there. Most important change is that it now requires Java 17 or higher. Support for draft-ietf-acme-dns-account-label and Actalis CA has been added. Resource consumption has been optimized for heavy workloads.

Even though it's a major update, there shouldn't be much to change on your side.

https://codeberg.org/shred/acme4j/releases/tag/v4.0.0

v4.0.0 - shred/acme4j

- acme4j now requires Java 17 or higher - A new `HttpClient` instance was created for every request. Now it is bound to the `Session`, reducing resource consumption on heavy workloads. (Thanks to @vincentdo for the PR.) - A `Session` instance can now be shared between multiple threads, still ke...

Codeberg.org
Buypass terminates the issuance of GoSSL Certificates. Last orders will be on October 15, 2025. Acme servers are terminated on April 15, 2026.

https://community.buypass.com/t/y4y130p
Buypass Terminates Issuance of GoSSL Certificates

As of 15 October 2025, Buypass will no longer issue TLS/SSL Certificates, including GoSSL Certificates. We will accept applications for GoSSL Certificates until 15 October 2025.

Buypass AS

IP address certificate subjects are coming to Let's Encrypt SOON™: https://community.letsencrypt.org/t/getting-ready-to-issue-ip-address-certificates/

The groundwork for this was started ~2020 so it's extremely cool to see it coming to fruition !

Getting ready to issue IP address certificates

Is there anything public available on which IPs will be able to get certs? I mean, obviously private/reserved ranges won't be available, but how about all those "cloud" services that rent IPs by the hour (or second)? Is it expected to be "normal" that someone could release an IP back into a pool and yet still have a valid certificate for almost-a-week, or will Let's Encrypt certificates only be available for IPs that are slightly less ephemeral?

Let's Encrypt Community Support

Dear #Letsencrypt, you helped secure millions and millions of servers, not just web servers. But your announcement at https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ about ending Ending TLS Client Authentication Certificate Support in 2026 because Google changes their requirements would result in your certificates becoming a possible risk for ensuring SMTP traffic. Please think again. Please.

1/5

Ending TLS Client Authentication Certificate Support in 2026

Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026. Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action. However, if you use Let’s Encrypt certificates as client certificates to authenticate to a server, this change may impact you. To minimize disruption, Let’s Encrypt will roll this change out in multiple stages, using ACME Profiles:

Let‘s Encrypt describing their ACME profiles in detail:

‚classic‘: 90 days, all as before
‚tlsserver‘: 90 days, smaller certs, cut lean for its server role and modern clients
‚shortlived‘: ~6 days, otherwise like ‚tlsserver‘

If you have no idea what the mentioned TLS extensions are about, do *not* configure a profile. But if you do, use classic.

If you have a rough idea and serve modern clients, tlsserver cuts some bytes and the auth process is tighter.

https://letsencrypt.org/docs/profiles/

Profiles

A profile is a collection of characteristics that describe both the validation process required to get a certificate, and the final contents of that certificate. For the vast majority of Let’s Encrypt subscribers, you should never have to worry about this: we automatically select the best profile for you, and ensure that it complies with all of the requirements and best practices that govern the Web PKI. But some people might be interested in proactively selecting a specific profile, so this page exists to provide the information necessary to make that choice.

#acme4j v3.5.1 is available. It's a small bugfix release. If Java modules are used, Buypass and Google CA `acme:` URIs were not recognized. This is fixed now.

https://codeberg.org/shred/acme4j/releases/tag/v3.5.1

v3.5.1 - shred/acme4j

* Buypass and Google `acme:` URIs were not recognized when Java modules were enabled, fixed. * Main development has moved to [Codeberg](https://codeberg.org/shred/acme4j). The project remains fully mirrored on [GitHub](https://github.com/shred/acme4j). You can open issues and pull requests on bo...

Codeberg.org

I moved the #acme4j repository to #Codeberg https://codeberg.org/shred/acme4j

Although it is the main repository now, the GitHub repository will serve as a full-featured mirror. You can post issues and pull requests in both repositories.

acme4j

Java client for ACME (Let's Encrypt)

Codeberg.org

#acme4j v3.5.0 is available. It adds support for Google CA and Buypass, as well as ACME profiles. Please see the release notes for further information.

https://github.com/shred/acme4j/releases/tag/v3.5.0

Release v3.5.0 · shred/acme4j

Changelog Added providers for Google CA and Buypass. See the documentation for their acme: connection URIs and further notes. Added support for draft-aaron-acme-profiles-00 (thanks to @jmcrawford4...

GitHub

Timeline on Let's Encrypt disabling OCSP.

If you use Apache ACME, and have set "MDMustStaple on", you have to switch it off in your config for LE certificates. Otherwise renewals will fail from March 2025 onwards.

https://letsencrypt.org/2024/12/05/ending-ocsp/

Ending OCSP Support in 2025

Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (OCSP). Today we are providing a timeline for ending OCSP services: January 30, 2025 OCSP Must-Staple requests will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension May 7, 2025 Prior to this date we will have added CRL URLs to certificates On this date we will drop OCSP URLs from certificates On this date all requests including the OCSP Must Staple extension will fail August 6, 2025 On this date we will turn off our OCSP responders Additionally, a very small percentage of our subscribers request certificates with the OCSP Must Staple Extension.