Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-5928

Improve the basic EFF ACME protocol implementation

    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-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)

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                johan Johan Eklund
                Reporter:
                johan Johan Eklund
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 1 week
                  1w
                  Remaining:
                  Remaining Estimate - 1 week
                  1w
                  Logged:
                  Time Spent - Not Specified
                  Not Specified