v2.16

• S/MIME module now also supports RFC-7508 style header protection. Thanks to @augjoh for help!
• EmailProcessor.smimeMessage() is now deprecated, see the migration guide. It only affects the acme4j-smime module and is quickly resolved.

Note that the S/MIME module is still experimental. I appreciate your feedback!

There is an official acme4j Mastodon feed for release announcements and other acme4j related stuff: @acme4j@foojay.social. Thanks to foojay for providing the instance.

v2.15

• S/MIME module now also supports the S/MIME validation of incoming challenge e-mails. There was a minor breaking API change for that, see the migration guide. It only affects the acme4j-smime module and is quickly resolved.

Note that the S/MIME module is still experimental. I appreciate your feedback!

Next I am planning an acme4j v3.0.0 release with the following major changes:

• acme4j-utils will be merged with acme4j-client, which means that BouncyCastle will be a hard requirement starting with v3.0.0.
• Starting with v3.0.0, acme4j will adhere to semantic versioning.
• acme4j will now require the second to current Java LTS version. This means that starting with v3.0.0, Java 11 or higher will be required. With the prospect release of Java 21 in September 2023, Java 17 will become the minimum version, and so on.

acme4j v2 will still be maintained for a while, but will only experience security updates.

For the upcoming v3.0.0, I also appreciate your input and feedback. Thank you!

v2.14

• CSRBuilder and SMIMECSRBuilder have a new method addValue() that allow to set further non-standard CSR attributes. Thanks to @kimmerin for the contribution!
• The new method Dns01Challenge.toRRName() helps building the DNS resource record name for the TXT record needed for domain name validation.

v2.13

After a much too long time, there's a new release of acme4j!

• acme4j-smime: Moved from JavaMail to JakartaMail. Sadly this is an API breaking change in the S/MIME module. See the migration guide for further details.
• Workaround for an Android bug that only returned an empty certificate chain (issue #127). Thanks to @NielsMasdorp!
• Added a debugging chapter to the documentation.
• acme4j is now tested to work on Android. However, please note that Android is not an officially supported platform.
• Minor bugfixes

v2.12

• Add support of RFC 8823 for ordering S/MIME certificates (experimental) (documentation)
• It is now possible to register generic challenge implementations (documentation)
• New method Login.bindChallenge(URL, Class) helps binding to a challenge of a known type
• Documentation got a FAQ and some minor enhancements

About the new S/MIME support, please note that the implementation is experimental, and has only been unit tested against the RFC so far. Your feedback is welcome.

Also note that Let's Encrypt does not issue S/MIME certificates (discussion see here).

v2.11

• New method Certificate.getAlternateCertificates() helps getting alternate certificates.
• Enhanced documentation of the example client.

v2.10

This is mainly a maintenance release that took much too long for deployment.

• acme4j now uses true Java 9 module-info definitions. It has no impact on your code if you don't use the Java 9 module feature, and should have no impact if you do so. Anyway, your feedback is very welcome.
• Account.getOrders() is required by the ACME specs, but not implemented by Let's Encrypt. acme4j now gives a verbose exception if this functionality is used, but not supported by the CA. See #74 and letsencrypt/boulder#3335.
• Up to v2.9, acme4j has cached the directory resource for 1 hour. This could lead to problems because incomplete directories and error conditions were cached as well. Starting with v2.10, acme4j now behaves RFC conformous and evaluates the CA's cache headers. Unfortunately it means that for Let's Encrypt, the directory resource is never cached at the moment. See issue #88 and letsencrypt/boulder#4814.
• JSR305 null-safe annotations are not compatible to Java 9 modules, and have been replaced by SpotBugs annotations. This should have no impact on your code, except of possible null deferences that have been undetected before.

v2.9

This is a minor release, unless you are using the STAR (RFC 8739) extension.

• STAR support was updated to match the RFC specifications.
• challtestsrv client now supports SERVFAIL and CNAME records, in case you need them in your integration tests.
• tls-alpn-01, STAR and IP identifiers got their own RFC numbers now, so the documentation was updated.
• Some more small documentation changes.

I'd like to dedicate this release to all the doctors and nurses who are fighting for the lives of Covid-19 diseased. You are truly heros! Thank you!

v2.8

• Login.bindChallenge() was mentioned in the documentation, but missing. Thanks to @AndersGM for finding and fixing it.
• Session.networkSettings() can be used to change the default network timeout of 10 seconds. Thanks to @m42s.
• You can now use KeyPairUtils.createKeyPair() (without any parameters) to generate a standard key pair. It will generate a fresh secp384r1 EC key pair. Thanks to @april.
• A Challenge can now also be found by their class type instead of a type string, which makes finding a challenge type safe. See the migration guide for details.
• The new method Account.hasExternalAccountBinding() indicates whether the account has an external account binding. Account.getKeyIdentifier() returns the key identifier of the external account binding.
• CertificateUtils now offers methods for creating test certificates, as well as test root and intermediate certificates. Thanks to @menzani.
• BouncyCastle is mentioned as official dependency now. However, you can still avoid BouncyCastle (and acme4j-utils) if you have other means of generating key pairs and CSRs. Thanks to @jvanhill for the pointer.
• A few minor bug fixes.

And last but not least, the documentation is now generated by mkdocs instead of maven. It looks modern, offers content search, and it can also be read on mobile devices now.

This release took much too long. The reason was an incubating mock framework that blocked continuous releases. It has been moved to a separate branch for now. I'm sorry about that, and I thank you for your patience. 😄

v2.7

IMPORTANT: All acme4j versions < v2.5 will stop working as of November 1st, 2019. Make sure to use v2.5 or higher in due time! See here and here for details.

---

• The ACME draft has been finalized and is now called RFC 8555. For this reason, the acme4j API is now considered stable. There won't be breaking changes to the public part of the API unless absolutely necessary.
• acme-star's recurrent-certificate-predate fields are supported now.
• In a preparation for Java 9 compatibility, Automatic-Module-Names have been added to the module's manifests.