Major TODOs:

• Include ACME in where "ejbca.productionmode=true" once the module is production ready.
• ECA-5627 CAA support. See https://tools.ietf.org/html/rfc6844
• Refactor and create ACME CLI out of the system/JUnit test client to make the PoC possible to to try out from scripting.
• GUI management of GlobalAcmeConfiguration, AcmeAccounts, AcmeOrders (connected to EEs and certificates), AcmeAuthorizations and AcmeChallenges
• Rate limit actions per account and add support for pre-registrations with email validation using external account binding mechanism. See https://tools.ietf.org/html/draft-ietf-acme-acme-06#section-10.3
• - Test and enable DNS challenge validation (with library included in ECA-5627?). Implement TLS-SNI and OOB challenge validations. See {@link org.ejbca.ui.web.protocol.acme.logic.AcmeOrderSessionBean#createAcmeAuthorization(AcmeIdentifier, String, long, String)}
• - Additional validation of domain names (e.g. black list for example localhost.localdomain by default that we use in our system test). See https://tools.ietf.org/html/draft-ietf-acme-acme-06#section-10.5
• Implement persistence that isn't just in-memory
• ECA-5711 Implement missing RaMasterApi calls and caching of commonly fetched objects.
• Document required authorization rules when running over external RA

Additional not so nice things with the current implementation:

• There is no challenge-response for the email address provided by the account holder
• An account (once registered) may request certificates from any configuration ID
• Since we shove all account related data into the AcmeAccountData object (to keep the PoC schema change at a minimum), db searches and parallel operations will be limited.

Nice to have:

• Improved and extended JavaDoc
• Documentation and test of Apache HTTPd integration
• Better clean up in test e.g. remove all certs issued by test CA and all EEs
• Cryptographic verification of accounts' contact info (email). Shared secret in GlobalAcmeConfiguration could be used to create invite tickets HMAC(secret, {contact info, createdTime, expireTime}

  ) that is sent to the contact info and verified during account registration ("external account binding"). Additionally, we would need:

  • prevention of contact info updates (or a similar process where invite ticket is sent to old email with new info).
  • a flag in each AcmeConfigation if a verified account is required or not
• Each AcmeAccount could have a list of allowed configurationIds (or a "allow any" setting).
• Detect "certbot" User-Agent behave in a backwards compatible way (under the condition that it now complies with draft 02 or higher)