Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Duplicate
-
Affects Version/s: EJBCA 6.8.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Epic Link:
-
Sprint:EJBCA Sprint 13
Description
Major TODOs:
- Include ACME in where "ejbca.productionmode=true" once the module is production ready.
ECA-5627CAA 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-5711Implement 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)