ACME v1 End of Life concern due to stale API libaries

Issuance Tech
1

I ran across this recently as I was attempting to register a new domain in our development environment during one of the black out windows (great idea to black it out during certain periods):

While I do understand the desire to move on from ACME v1 to the v2 protocol, I think the current process is a bit rushed and is going to cause quite a headache for us. The reason is that the library we decided to implement our Lets Encrypt certificate support using is this one:

Unfortunately at the time we started using this, the new .net core version was in the alpha stages and we were not currently in a position to develop with .net core. So we stuck with this library and I was hoping it would be actively maintained. Alas as it turns out, no new development is happening on this old library as it has all moved to the new .net core version:

The catch however is that there was never any support for ACME v2 in the original library, as that was only done in the .net core library. The other rather unfortunate consequence of this is that when the developer decided to move to .net core, he also decided to completely revamp the entire API and effectively develop it from scratch. So while they share the same project name, alas they do not share any API compatibility so moving from the original library to the new library means a complete re-write of our existing tools :frowning:.

I have asked if there are plans to consider moving the old library over to using the v2 protocol, but I honestly have no idea how much work that is and it would appear the original authors have no interest in doing this.

So I do wonder if this time frame is a bit accelerated for some people?

1 Like
2

Have you considered migrating to Certes, which is compatible with either runtime?

ACME v1 and ACME v2 have fundamentally different flows and requires clients to do a partial rewrite anyway. The API of library that was built for ACMEv1 wouldn’t be able to transparently upgrade you. There’s coding involved either way.

My own experience has been that it’s usually possible contain your interaction with ACME (registration, authorization, issuance) to a ~single generic “RequestCert” function, which makes moving between libraries straightforward. YMMV.

3 Likes
3

Thanks for the reply. Good to know that the v1 protocol is quite different to v2, so I guess we are stuck having to do a re-write anyway :(.

Not familiar with Certes, but considering we will need to pretty much re-write all this code to support v2, I will give it a look and compare it to ACMESharpCore. One of the things that our implementation does is interface directly with our Cloudflare account to manage the DNS for the hosts we are generating the certificates for. Hopefully there will be some kind of hook to support that in both libraries.

Thanks for the suggestions!

1 Like
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.