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

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

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Major Major
    • 1.5.5.Final
    • None
    • API / SPI
    • None

      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!

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

              Created:
              Updated:
              Resolved: