Why ACME requires domain auth first before CSR?

Issuance Tech
1

I am trying to integrate ACME V2 for a commercial CA, but the CA requires CSR first, then do domain auth, which is conflicting with ACME defined.

My question is:

  • Why ACME requires Authz before CSR submitting(finalize)? In another word: Why CSR first does not making sense? Modifying CA’s authorization issue fluent means extra infrastructure audit cost.
  • Is there any way to work-around?
1 Like
2

Hi @xiaohuilam

I don't understand your question.

You can

  • first create a CSR, then start a new order, then do the challenges, then upload the CSR (or)
  • start a new order, confirm the challenges, then create and upload the CSR

It's your decision, it's not a problem of the ACME-protocol.

It's a question how to create a client.

3

Thanks for your reply. and sorry for my English expression.

I mean that, traditional CA (born before ACME existence) 's fluent to issue cert are these steps.

  • Subscriber(Client) generate key-pair, make CSR request and submit it to CA.
  • CA responds domain authorization credentials (DNS/HTTP、TLS/E-mail).
  • Subscriber complete the domain auth(upload file to server, or add new DNS record CA provides). Then trigger check auth process.
  • CA issue certs if everything goes well.

So we can figure it out, traditional fluent is CSR First then subscriber can receive domain auth challenge.
But ACME reversed these two steps, it wants Domain auth challenge first, then CSR(finalize).

I’m not sentencing anything here, I just want to tell foundation, the ACME fluent is try to improving costs that traditional CA to implement ACME.

4

Why should the ACME protocol check the CSR if the challenge isn't confirmed?

That's not required.

It's the problem of the traditional CAs that they want the CSR first. They "think" the client is able to confirm the challenge. But that may be wrong.

Confirming the challenge there are a lot of problems possible. So the ACME protocol has it's own rules.

But there are clients that allow to reuse a CSR.

5

Hi @xiaohuilam,

The CSR contains a public key which is a large object when compared to other objects the ACME CA needs to store during the ACMEv2 issuance flow. If you accept that up front and the client never bothers to actually authorize the domain or finalize the order, or if one part of the authorization fails, then you’ve wasted disk space and performed inefficient operations.

5 Likes
6

Yep. It should be a weakness point if csr first.
But I think there’s some way to solve trade-off them both, eg: let ACME SERVER to decide csr first or domain auth first,

After all, the community needs to figure a way out to help other CA implement ACME protocol. It’s helpful to spread ACME.

7

@xiaohuilam,

I believe the best path forward would be to follow the ACME spec as defined by RFC 8555. Please see the following pages

1 Like
8

Unfortunately you're too late to provide input into RFC 8555's design. It's set in stone with the exception of errata.

I recommend that if you have thoughts on extensions or changes to the ACME protocol that could be specified in additional add-on RFCs you should propose them in the IETF working group on the mailing list.

2 Likes
9

Ok, I see.

I am newbee for mailing list (don’t know how to proposal). Can I just proposal a Pull-Request on https://github.com/ietf-wg-acme/acme/ directly?

10

I'm afraid I'm an IETF newbie myself and my advice here is limited :slight_smile:

Opening a PR on that repository won't be the correct action. That repository is basically frozen now: it's the text that was used for RFC 8555.

In this case something like you're proposing would need to be written up as a brand new "internet draft". This page has more information: IETF | Internet-Drafts

11

If I remember correctly, this order was intentionally changed between ACMEv1 (the pre-standardization draft version) and ACMEv2 (the standardized version), so probably there is a history of discussion about this issue and the rationale for it in the IETF process. (If so, that would also make it harder to change in the future, because the current version represents an intentional decision after a debate.) @jsha, do you happen to have a reference to when or how this discussion occurred?

2 Likes
12

I think a lot of the discussion happened off-of this one thread: https://www.mail-archive.com/acme@ietf.org/msg01994.html

It looked like it forked and was also linked to a discussion about proactive issuance so it may be a little tricky to follow.

1 Like
13

Yes, to be clear LE / myself specifically wanted this protocol flow. I would not be supportive of implementing anything else at Let's Encrypt.

14

In that case conceivably ACME could be extended to support another option for other CA adopters, but it might be very difficult in terms of client compatibility because, by default, ACME client software would not understand how to use that extension. It would probably be a lot of work to get client-side implementations to add it, since there are quite a few developed independently and most of them currently use the RFC 8555 method as published. In order to retain compatibility, the extension would presumably need to allow fall-back to the standardized method if the client didn’t support it, which might not satisfy CAs that want the other order.

2 Likes
15

Thanks to @cpu for the link! As @Phil mentioned, we specifically introduced this flow because we wanted to minimize the amount of state required for abandoned orders.

I believe that at the time we asked other potential implementers to come forward if the CSR-last flow would cause any problems. We didn't get much feedback, but what we did get seemed to indicate it wouldn't be a problem.

I'm sorry that the CSR-last flow introduces more work to integrate with your existing CA software, but I think you will find that if you take the time to make the changes, they will be worthwhile!

Thanks,
Jacob

16

But I think it would be a problem,

  • Original CA seems have the capability to implement, just need to re-audit after it.
  • Reseller can’t until CA support CSR-last.

Why we need to think about reseller? There’re some certificate authorities haven’t update their infrastructure softwares for decades, Their only hope to get ACME supports seems that maybe some 3rd helpful reseller build it for them.

17

That is more a argument to detrust them because they lost the capability to react to security threats, than a valid argument for a protocol change request.

1 Like
19

How about resellers?

20

That’s a good point! It does seem like it’s hard to fully implement ACME at the reseller level, without support from the CA.

Here’s a thought: Does your CA partner keep validation information around for a certain amount of time? Could you submit a dummy CSR in order to trigger validation, then throw away the results, and perform real issuance using an ACME CSR? Note that you would need to be sure that the CA wouldn’t actually issue a certificate based on the dummy CSR, since that would mean that you as a reseller were in posession of a private key for the certificate (which is a bad idea because it increases the severity of breaches).

22

It could work for some CA, but some doesn’t.
Likes COMODO, which renamed into Sectigo, it’s domain auth HASH is generated from sha256 for CSR file it self. so this ways won’t work.

  • After dummy CSR domain auth passed
  • Upload real CSR
  • Domain auth changed and need to re verify