Curious if anyone has played around with it yet. The main post doesn’t talk about pricing or rate limits aside from needing to use EAB to associate the acme account with your Google Cloud account. But there’s a link to another post talking about their Certificate Management feature that says the first 100 certs are free. Subsequent certs up to 2000 are $0.20/cert/month and $0.10 after that. I would assume that only counts currently valid certs.
Seems like another potentially good backup CA option for relatively low volume users.
By default all certificates issued by Google Trust Services are good for up to 90 days; however, ACME allows for clients to request certificates with different validity periods. Using this capability we allow the requestor to get certificates that are good for as little as 1 day, though we would not recommend using anything less than 3 days due to concerns over clock skew and certificate validity overlap.
Looks like a bunch of ACME libraries and clients will need to add notBefore and notAfter support to order creation!
Wow, the real news is that pki.goog is available to everyone now. It used to be available only for Google services (example: you point your domain to blogger or Google Sites)
And using acme is really good.
Certificate management is another thing, I believe: manage any certificate for gcp services. Someone with access should see and check the actual pricing for the public CA.
It is that simple. Just schedule this task to run periodically and you will now be automatically acquiring and maintaining the TLS certificates for the associated workload.
I've actually used this in alpha/beta last year to help see if it integrated properly with Certify The Web (there were a few tweaks). Having an ACME CA with an SLA and support is pretty cool. The more the merrier!
Honestly, I had forgotten these were even in the spec for Order objects until I got home and double checked. I had figured the CA would pull the values from the submitted CSR. And now I'm wondering whether any of them actually do (those that actually support configurable lifetimes).
Woah there. Ryan may not be a certbot user but he knows a whole hell of a lot about PKI (probably more than anyone here), let's not pile on. The command is an example posted in a blog and you just have to use certbot the way you always use it.
Maybe the Certbot example wasn't even written by him, but by his co-author Babi Seal, who knows. I'm assuming Ryan is "first author" though and, I think, ultimately responsible for the contents of the blog post.
Having a heck of a lot of expertise in field A doesn't really warrant you posting strange and incorrect stuff in field B IMO.. Usually, you'd do your digging and finding out how it's suppose to work, before posting something, right? Due diligence and stuff like that.
Combining --standalone and --preferred-challenges dns should result in an error due to incompatible challenges.
Edit: Just checked and indeed, an error: "None of the preferred challenges are supported by the selected plugin" That's just sad.. It seems they haven't even tried out their own example..?
Thanks @Osiris I don't care about the command being wrong, I care about openly mocking Ryan (who is/was an advisor to the Let's Encrypt board) in a public forum because of a bad copy/paste. I'll ping him and ask if he can get the command fixed.
after thinking some about it I'm not sure allow setting notbefore and notafter by user good idea:
can it be set to backdate/predate the certificate?
like set notbefore 2 months ago and set notafter next month
or a cert that valid from April 30th to July @webprofusion if you still have access can you try backdating/predate the certificate? how far Google will allow?
I know GTS by default bactdates certificate by an hour (notbefore time vs timestamp on SCT)
I just tried it, they allow a notBefore of up to -2 hrs: Requested NotBefore timestamp: 2022-03-25T09:29:34.5410277+00:00 must be within [2022-03-30T07:29:34.912389236+00:00, 2022-03-30T09:29:34.912389236+00:00].
Hello, my name is Ryan Hurst, I am the Product Manager for Google Trust Services. I am also an advisor to ISRG and Let's Encrypt.
First I want to apologize for the incorrect command line in the post. That issue has now been resolved.
As for how it happened I relied on someone else to test the original command line in the post and at publication, time was asked to make a change to the command line and did so without re-testing. This mistake is on me.
It seems there are a few questions implied and explicit in this thread I should try to address.
What does Cloud Certificate Manager charge for?
Cloud Certificate Manager charges for managing certificates, not the certificates themselves.
In fact, it sources certificates in some cases from Let’s Encrypt. Since this is the client dev forum it might be interesting to know that it makes the decision on which CAs it can use based on the CAA record for a given domain,
What does this ACME capability cost?
There is no charge for using the Cloud Certificate Manager ACME service.
What was the goal of release?
It is intended to augment the managed offering and enable Google Cloud customers to get CA redundancy when using ACME, as well as enable them to use Google Trust Services issued certificates in their larger deployments so they can have uniform device ubiquity across deployments.
I am happy to answer any questions folks may have.
while it's not directly related with this if may better to publish CAA record for GTS somewhere more visible then deep corner of CPS pdf file (section 4.2.4), like in FAQ.
P.S: it's pki.goog
