[jboss-jira] [JBoss JIRA] (ELY-1629) Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change

[Daniel McCarney (JIRA)]

     [ https://issues.jboss.org/browse/ELY-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel McCarney updated ELY-1629:
---------------------------------
    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|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key-rollover/68953] 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!


  was:
Hi folks :wave:,

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|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key-rollover/68953] 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!




> Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
> ------------------------------------------------------------
>
>                 Key: ELY-1629
>                 URL: https://issues.jboss.org/browse/ELY-1629
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>            Reporter: Daniel McCarney
>            Assignee: Darran Lofthouse
>
> 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|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key-rollover/68953] 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!



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)