Uploaded image for project: 'WildFly Elytron'
  1. WildFly Elytron
  2. ELY-1629

Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change

    XMLWordPrintable

Details

    • Feature Request
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Done
    • None
    • 1.5.5.Final
    • API / SPI
    • None

    Description

      Hi folks,

      First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.

      I wanted to file an issue with the maintainers to provide a heads up about an upcoming backwards compatibility breaking ACME change that I think may affect your project based on this code snippet:

      https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac86bff0a5a2668805b978aa507/src/main/java/org/wildfly/security/x500/cert/acme/AcmeClientSpi.java#L376

      While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change

      Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.

      Thanks!

      Attachments

        Issue Links

          Activity

            People

              fjuma1@redhat.com Farah Juma
              ccppuu Daniel McCarney (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: