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.

v2.6

• Certificate can now also be revoked when only the account keypair and the certificate is available, via Certificate.revoke(Login, X509Certificate, RevocationReason). Thanks to @aloopkin.
• acme4j could not connect to remote Pebble servers, fixed. Thanks to @aloopkin.
• draft-ietf-acme-star-04 is supported now, bringing optional GET requests for STAR certificates.
• tls-alpn-01 certificate generator now also supports IP certificates.

v2.5

The only change is that the pre-draft-15 compatibility code has been removed.

I recommend to update to this acme4j version soon. Let's Encrypt posted a sunset date for the old GET requests on November 1st 2019. acme4j < v2.5 will stop working after that date. (acme4j v1 is also affected.)

If you use acme4j to connect to a server that does not support ACME draft-15 yet, you should not update to acme4j v2.5 before the server has been updated. The Boulder (Let's Encrypt) and Pebble ACME servers both support draft-15.