0

ACME is used by some certificate authorities to process automated signing of certificate requests and issue resulting certificates.

An increasing number of applications (Eg Traefik) now have builtin support for ACME. This is very useful for managing certificate cycling without tracking where every deployed application stores its certificates.

However "free" certificates from letsencrypt and similar certificate authorities are not always appropriate for all applications. Such examples include some software requiring the exact same certificate being installed in multiple layers of an application's edge gateway (yes this does happen).

I'm wondering if, hypothetically, ACME v2 can be used to redistribute existing SSL certificates and associated private keys. Or is it only capable if responding to CSRs where the private key is never transferred between ACME server and client?

Philip Couling
  • 13,581
  • 5
  • 53
  • 85

1 Answers1

0

ACME is defined by RFC8555 currently.

There is nothing that prevents other CA to use it, besides Let's Encrypt, and indeed there are other CAs existing using it, and others adding it to their existing API.

The key associated to a certificate should never travel. The CA shouldn't know it. As such, there are no operations in ACME that would allow a CA to send the key, besides the certificate, and that is a good thing.

Retrieving a certificate is a core operation, see "7.4.2. Downloading the Certificate". It could happen separately/outside of a previous certificate request. The problem being then: how does the client know which URL to use to download a specific certificate (an information that it receives when doing the normal authorization/validation steps)?

There are other protocols to manage communication of cryptographic materials such as X509 certificates. Still in ACME, you might be interested in RFC 8739 "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)" which allows the CA to pre-generate certificates. And the related RFC 9115 "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates",

Outside of ACME, but very similar, you have RFC 8894 "Simple Certificate Enrolment Protocol" (but still no transmission of private key).

But you are not clearly describing the problem you have around "redistribute existing SSL(sic) certificates and associated private keys". What else do you really need besides an URL that gives back that data if it is that you want to send back to client (but again: making the private key travel is, in general, a bad idea)? Is authenticating the client the problem? Discoverability of the URL to use to download a specific certificate/key?

Patrick Mevzek
  • 10,995
  • 16
  • 38
  • 54
  • I agree with the words "bad idea" except... edge / not-so-edge cases where it's unavoidable. Example A) one particular gateway server decrypts, routes, and re-encrypts the traffic. This software requires the same identical certificate be installed in the edge gateway as the application. *(I didn't build it)*. B) many of us use cloud infrastructure with no static storage beyond something like encrypted NFS and/or the cloud providers's secrets manager. There PKs must move or fear the rath of [rate limits](https://letsencrypt.org/docs/rate-limits/) when containers or nodes cycle. – Philip Couling Jul 28 '22 at 20:57
  • In short, engineering all our software estate to fetch PKs and certificates from a secrets store is too large a task to implement. With ACME on the rise I was hoping the problem might age out by way of shoe-horning redistribution through ACME. *Alas no*. – Philip Couling Jul 28 '22 at 21:02
  • As for A) Look at RFC 9115 as this is exactly that use case. As for B) store the private key in whatever secrets manager you have around. The private key can remain the same even if the certificate change because expired (even if it is also a good idea to rollover keys) – Patrick Mevzek Jul 28 '22 at 21:25
  • "With ACME on the rise I was hoping the problem might age out by way of shoe-horning redistribution through ACME. " You can certainly build on top of it something specific to your need, but I do not see what ACME brings as useful to you. You just seem to need one URL where some input parameters give back a certificate and a key. What else do you need? ACME defines account operations, certificate requests, validation, revocation lists, etc. all stuff that seem out of your needs. – Patrick Mevzek Jul 28 '22 at 21:27
  • What I need is to retrofit that logic to like 500 pieces of software built in various technologies. Since may of them already, or will sometime "soon" support ACME, it was just a hope that I could sidestep that work with some type of certificate store with an ACME front-end. – Philip Couling Jul 28 '22 at 21:51