@orangepizza I'll get a FAQ item for CAA added to pki.goog.
4 Likes
@9peppe Yes, I agree the current documentation is a bit unclear, we have edits in the work that should address this before public preview.
4 Likes
It can also be added to the meta field caaIdentities of the "ACME directory", such as with LE:
https://acme-v02.api.letsencrypt.org/directory ->
{
"keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
"website": "https://letsencrypt.org"
},
"newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
"newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
"revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert",
"ysn4oX0TJZk": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417"
}
@rmhrisk Regarding "Just schedule this task to run periodically (...)" in the blog, please see the certbot renew subcommand.
7 Likes
this make me raise a question, if a ACME client given API for edit dns record for domain A and CAA currently not allow the CA it configured to ask certificate would it ethical to client insert that CA into CAA record of the domain A?
what if explicit --server option was given so user give intention to use that CA?
IIRC cloudflare does that for their "universal certificate" Certificate issued despite CAA record
6 Likes
There is likely a checkbox one must click that allows CF to make such a DNS edit (on your behalf).
4 Likes
@jvanasco I can appreciate your concern and as a long time supporter of Let’s Encrypt and advocate for encrypting the web I want to be clear I don’t aspire for anyone to change from Let’s Encrypt to Google Trust Services.
The way I personally look at this is that for the large majority of the web TLS is now mandatory and unfortunately despite that fact, TLS is still pretty fragile. I believe there are a number of things that need to happen to address this fragility but one of them certainly is more ACME-enabled CAs.
The more of these CAs there are, the more robust the ecosystem will be.
Clients can, like Caddy as an example, failover from one CA to the next, or rotate across CAs if there are multiple to choose from. The failover behavior helps users have continuity in the event of a CA unavailability for any reason while CA rotation helps ensure should there be a need to switch CAs for any reason that it is possible to do so without disruption.
Similarly, there are some organizations that have policies that prevent them from using services without contractual SLAs. This reality has prevented some organizations from adopting Let’s Encrypt. It is my hope that the availability of our service could help them feel more comfortable doing so because they can now have multiple providers with separate infrastructure reducing the dependency on any single service.
The decision on which service providers to use is a personal one and I certainly understand that our offering wont be right for everyone. That said I do hope it helps make TLS more reliable and ubiquitous.
10 Likes
If I may add "free", as in, "free beer", then: hear hear!
Note that "free beer" is not the same as the "free" in "if you're not paying for it, you're the product" 
9 Likes
Note that CA rotation isn't always possible or advisable.
CAs have different features, for example GTS issues certificates for IP addresses and has an older root certificate, while Let's Encrypt offers an entirely ECDSA chain on request.
LE and GTS are not fungible, not for me at least.
6 Likes
Agreed. CAs are not always fungible though over time I imagine that will be more true.
As for selecting an ECC issuer if the CSR has an ECC key, I do expect us to support this in the future.
4 Likes
@Osiris
Inclusion of the CAA identity in the ACME dictionary is fair to request and thankfully an easy one to incorporate, I have created a tracking issue and we will add it in the near future.
7 Likes
That's good.
As for key types, I read in the CPS that you support P-256, P-384 and RSA >=2048 bit... up to what, and with what granularity? (Yeah, it's just curiosity, no self respecting person would use an RSA 8K or 16K certificate)
Let's Encrypt I think only supports 2048, 3072 and 4096 for RSA.
5 Likes
Appendix B of the CPS states most of the rules that are applied to RSA keys on validation of requests. That said the minimum is 2048 and the maximum is 4096. Let me know if you have any other questions.
3 Likes
To be honest, I don't know if there are ACME clients out there actually using the caaIdentities meta field, but there are "1,540 code results" for it on Github 
5 Likes
Google has a long history of abruptly deciding to entirely cancel product lines or deciding a freemium based product will suddenly require paid subscriptions. Consumers leveraging solutions like Google Trust Services are inherently investing their resources into what could suddenly become technical debt or a high-priced vendor lock in.
This is very true, and speaks to the risks of assuming technical debt. Even LetsEncrypt's Boulder (production) and Pebble (development testing) ACME servers are not fully interchangeable; a proper ACME client can talk to both - but many (most?) clients are built to the feature set and implementation details that LetsEncrypt selected for Boulder. When large cloud platform providers offer their implementations of publicly standardized APIs like the ACME RFC, it's often accompanied with some upsell in corollary products to entice a platform conversion. A few years later, the "free" is typically reduced or eliminated, and consumers can't simply just switch their endpoints/credentials, as their integration started to (unknowingly) use the proprietary extensions or products.
Beyond that, there are countless moral and ethical reasons to not trust internal platform services to a company like Google, especially when there are plenty of free and robust alternatives. I avoid using Google technology as much as possible, and always recommend that others do the same.
7 Likes
I'm still bitter about Google Reader 
6 Likes
I appreciate the concerns over vendor lock-in. This is one of the reasons we are strong supporters of Let's Encrypt as well as ACME. It is also why I stressed above our goal is to provide the infrastructure that enables TLS to be less fragile over time.
With that said we fully appreciate that not everyone will want to use our service and that is OK 
We all take a critical dependency on TLS and we want to do what we can to make sure it can be as reliable and ubiquitous as possible.
7 Likes
I'm still bitter about Google Reader
So am I
8 Likes
Hey @rmhrisk, where's the best place to report issues with the ACME server implementation?
It seems like neither the Staging or Prod endpoints support POST-as-GET requests for ACME account endpoints. If I send a JWS request with an empty string payload and the following header:
{
"alg": "ES256",
"nonce": "my-nonce-value",
"kid": "https://dv.acme-v02.test-api.pki.goog/account/a55BO3ATv2NHi9Pfo-7hdA",
"url": "https://dv.acme-v02.test-api.pki.goog/account/a55BO3ATv2NHi9Pfo-7hdA"
}
I get a 400 response with the following body:
{"type":"urn:ietf:params:acme:error:malformed","detail":"unable to parse JSON account: unexpected end of JSON input"}
Yet, the same basic JWS request against an order url such as "https://dv.acme-v02.test-api.pki.goog/order/bKXv34uWNieJ1tnCxbHMDQ" with an empty string payload, I get the order details in the response as expected.
5 Likes
Ah, I remember this being a problem for the challenge endpoint as well, which was fixed. Should this be against /account or /newAccount? When certify queries an account it uses /newAccount with {"onlyReturnExisting": true}, which works.
5 Likes