CAA for staging-only issuance?

9peppe · October 24, 2023, 7:28am

I have a subdomain I use as a staging/sandbox area. I thought it might be useful to restrict issuance that way, but I haven't thought about it very long and I'm not sure it makes sense.

Ideas?

orangepizza · October 24, 2023, 7:38am

github.com

letsencrypt/boulder/blob/main/va/va.go#L205


      
          		TLSPort:   443,
          	}
          }
          
          // ValidationAuthorityImpl represents a VA
          type ValidationAuthorityImpl struct {
          	vapb.UnimplementedVAServer
          	vapb.UnimplementedCAAServer
          	log                blog.Logger
          	dnsClient          bdns.Client
          	issuerDomain       string
          	httpPort           int
          	httpsPort          int
          	tlsPort            int
          	userAgent          string
          	clk                clock.Clock
          	remoteVAs          []RemoteVA
          	maxRemoteFailures  int
          	accountURIPrefixes []string
          	singleDialTimeout  time.Duration

current code only able to only one CAA domain name, so if we change that it'd be only able to holde staging-only names

Nummer378 · October 24, 2023, 11:24am

You can use CAA with the accounturi extension to only allow one or more staging ACME accounts.

9peppe · October 24, 2023, 12:29pm

No, not really. Accounts are provisioned automatically and pretty much thrown away after minutes/hours.

petercooperjr · October 24, 2023, 1:26pm

I mean, if you want to get really crazy, you could have your CAA record not allow anything (like issue ';'), and then have whatever pre-hook/post-hook/etc. type script you're running to get certificates change the record to something that allows Let's Encrypt only with the account uri you you're setting up in staging. And then change it back afterward.

But only if you want to get really crazy.

rmbolger · October 24, 2023, 5:28pm

From a raw ACME protocol perspective, there's no such thing as Staging/Sandbox. There are only CAs with directory endpoints. And for public CAs, they presumably have a unique CAA identifier.

Theoretically, Boulder in staging could be modified to do CAA checks against a different CAA identifier like letsencrypt.org.test, right?

But that would break staging for anyone who already has letsencrypt.org allowed until they updated their records to allow both unless Boulder was modified to accept either one in staging?

mcpherrinm · October 24, 2023, 5:51pm

I don't think we're likely to change this. Maybe if we'd thought of this a long time ago, we'd consider it, but today changing it would break a lot of existing staging users.

Account URI binding is going to be the best option here.

aarongable · October 24, 2023, 5:56pm

Additionally, changing this would prevent users from using Staging as a "check to see if my setup is definitely going to work with prod" system. If the CAA identifiers were different, it would be possible (likely, even!) to have CAA records that allow staging but block prod, or vice versa, and people might get frustrating failures.

9peppe · October 24, 2023, 6:18pm

yeah, I didn't imagine them different.

I did imagine letsencrypt.org covering both and staging.letsencrypt.org covering staging only. But that pretty much treats prod and staging as separate CAs, yes.

system · November 23, 2023, 6:19pm

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