This is more a "tech-chat" kind of query, but I didn't find a better suiting category than "Issuance Tech".

Let's say that, hypothetically, Let's Encrypt were able to validate a URI-SAN. Where in the ACME message flow would the URI-SAN be exchanged between client and server? Just in the base64uri encoded CSR? Or should the protocol specification be changed to accommodate for more SAN types than just DNS?

Background for this question is that we need to internally issue certificates that contain a URI-SAN as well as the RFC 9310 NFType extension using ACME. The question is now: What would be the best (in the sense of "likely to be compatible with future implementations of this functionality into existing clients") way to update our internal ACME implementation to support these types of certificates? I know that the NFType extension is a corner case, but URI-SANs are more and more common within cloud deployments (usually to carry a spiffe:// URI).

Hoping for your thoughts or hints on where to best move this discussion.

Yes. Currently ACME only supports the dns and ip ACME identifier types (Automated Certificate Management Environment (ACME) Protocol; it looks like email is only used for S/MIME certs).

Thus, for the uniformResourceIdentifier GeneralName of the SAN (RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to be somehow included in a certificate issued by ACME, a new ACME identifier is probably necessary. And probably also a completely new challenge.

With regard to your question and ACME client compatibility: I'm very doubtful URI-SANs are ever going to be implemented using ACME. So I'm also doubting any regular ACME client would use it. That said, if an ACME server allows such ACME identifier types and weird challenges, I don't think any existing ACME client without support for that would break.


Osiris is correct that you'd have to get both ACME Server and ACME Client support if you wanted to enforce some sort of validation on new identifier types. However, there's nothing technically stopping a private ACME CA from accepting and signing CSRs containing additional SAN types without validating them.


The best thing to do if you are hoping for standardisation is to formulate a proposal for an ACME extension (RFC) covering the parts you need to add, much like this one for Authority Token: RFC 9447 - Automated Certificate Management Environment (ACME) Challenges Using an Authority Token and TNAuthList RFC 9448 - TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token - it depends on how generic somethign is as to whether it needs to be it's own distinct RFC

So you likely wouldn't be updating RFC8555 RFC 8555 - Automatic Certificate Management Environment (ACME) itself, but proposing an extension to it.

I would suggest that your extensions would include the Order object, Authorization and Identifier types and include a method for including the identifier in the CSR possibly as an X509 extension, and you would generally implement a working draft with your own ACME CA server and ACME client (or extend another one).


I'll answer this question completely differently than everyone else:

In ACME v1 (no RFC), a Client/Subscriber would create a CSR then upload it to the ACME Server via the API. The ACME Server would then parse the CSR to extract all the data, perform the validations, then sign it.

In ACME v2 (RFC 8555), a Client/Subscriber creates an "ACME Order" via the ACME Server API. After validation of the domains is successful, the ACME Client creates a compliant CSR and uploads it to the ACME Server API. The RFC also indicates several things that "MUST NOT" or "MUST" happen in certain situations, and what fields are "optional". I suggest skimming the RFC for those 3 terms to see how and where there is flexibility.

The takeaway from this, is the current/future protocol is:

  1. inform the ACME Server of all the relevant details
  2. create a CSR for signing based off the approved and validated information

With all that being said, let's expand on @webprofusion's excellent advice above-- particularly this bit:

Applying his advice to your situation and the RFC, I would probably do the following (which is likely just clarifying what he is thinking above):

  • When making an ACME Order via the API, a client should indicate they want the URI-SAN support and provide all the relevant info in a specific way.
  • Extend the existing Authorization Objects and links (in the acme-order) to support this.
  • Indicate exactly how this should be formatted into the CSR

I would also note that a Client should validate the ACME Order object and the final certificate to ensure this information appears. Some ACME Servers will ignore extraneous information from requests and CSRs, others will fail the request with an error code. Your client would need to handle both scenarios.


Thanks all for your input!
I'm torn between "doing it thoroughly" by creating an extension RFC (I've never worked on an RFC before, let alone started a new one myself) that includes the uri and nftype types on the one side, and on the other side going with what RFC 8555 provides (only sending the dns identifier in the new-order request) and just add the additional requested fields only to the CSR. We use external account binding to authenticate against our CA, so one could make a point saying that this is already sufficient validation.

If I went the thorough way you have indicated that there would be a need to also specify how to put those fields into the CSR

@webprofusion wrote:
include a method for including the identifier in the CSR possibly as an X509 extension

@jvanasco wrote:
Indicate exactly how this should be formatted into the CSR

The uniformResourceIdentifier SAN is already specified in RFC 5280 and the nfType extension in RFC 9310. What else would need to be specified?

1 Like

That's handy! In that case I assume you'd just use those.

Regarding RFCs etc, realistically if you're implementing your own ACME CA (or extensions to one) and your own client extensions I'm not sure it really matters until you want to interoperate with external tools or CAs.


That's probably the catch - we also need an external vendor to interface with our CA. So the question is whether to fix the details merely in a mutual spec or "do it once and do it right" and define this via an RFC. We're probably not the only ones that will have the need to issue certificates in accordance to the 3GPP 5G specs in an automated way, so an RFC could prevent a proliferation of diverging implementations and in the long run reduce the efforts on all sides.

EDIT: cert-manager is the de-facto standard to get certificates in a cloud environment and an RFC could maybe also help in getting this into cert-manager's ACME client implementation.

1 Like

for Identifier adding rfc, see RFC8738 or RFC8823


For what it's worth I'd probably be interested in implementing a compatible ACME certificate manager for that, we already have telephony STIR/SHAKEN support in Certify The Web and we're headed towards a container based RBAC version of the same thing, so such niche certificate management scenarios are somewhat relevant to me.


The Right Way™️ to do this is definitely to define two new ACME Identifier types, have the client present them in the NewOrder request, and have the server reflect them in the Order object and its associated Authorization objects.

That said, you don't have to write an RFC to do this. The IETF adopts RFCs that represent "rough consensus and running code", so even if you did write an RFC, you'd be implementing this solution before that document is finalized. So just go ahead and implement it! Then if you think it is useful enough to be standardized, put forward a draft RFC (and yes, this one is a good example of what it would look like) so that others can benefit from your work.


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