The ssl.com staging server's certificate seems to be unmonitored,
causing the acme4j build chain to break from time to time when their
certificate has expired. As this is blocking development, I have
decided to disable all related unit tests, and add a corresponding
note to the documentation.
The acme4j ssl.com provider is marked as experimental now, since it
is not fully covered by unit tests anymore.
ssl.com requires EAB for account creation, but the metadata's
"externalAccountRequired" property gives "false", indicating that no EAB
is used.
This fix patches the read directory's metadata if the ssl.com provider
is used.
I like to avoid having different examples for different CAs or
scenarios, as it takes unnecessary time to keep them in sync and
updated.
For this reason, I merged both examples back in a single example again,
which now also handles EAB if necessary.
I also used a generic example CA (example.org) so no CA is favored in
the source code. The desired connection URI must now be configured
first, in order to make the example run.
The documentation was updated accordingly. Rationale is that I don't
want the documentation to be cluttered with all possible CAs, so none of
them is favored now.
- Rearranged all chapters. It makes content easier to find, as it is not
buried in unrelated information now.
- Reviewed the content.
- Fixed broken links.
- Added documentation about Renewal Information and Exceptions
With this change, it is not stricly required anymore to create the CSR
oneself. The Order class contains all information to generate a basic
CSR itself.
The separation of acme4j-client and acme4j-utils was a design decision
that should avoid BouncyCastle to be a hard dependency of acme4j-client.
Anyhow acme4j is not really usable without BouncyCastle, so acme4j-utils
is used in almost all projects anyway.
This merge allows to extend the client API with some nice methods that
will make it easier to use.
- Some Optional return values could only be empty if a method was
invoked although the server did not support that feature. In order to
keep the API simple, a newly introduced AcmeNotSupportedException is
now thrown in that case, so these methods will immediately return a
non-null value. There is always a method to check if a feature is
available or not, so the invoker can check in advance and does not
need to actively handle that exception.
- Some other places that previously threw an exception because of
missing features, are now also throwing AcmeNotSupportedException for
consistency.