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?

CodePudding user response：

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?