Not free (looks like $1 per domain name per month), but just announced today:
(The non-exportable certificates only usable within the AWS infrastructure are still free where you don't have access to the actual private key, but this expands their offerings beyond the paid "exportable" ones that used their own APIs to also offer ACME-based paid certificates.)
A quick read looks like all domain validations are done in advance and persist.
Authorization: The ACME server checks pre-configured domain validations. Because the endpoint uses PRE_APPROVED authorization, no live challenges are required from the client.
From: Issuing certificates through ACME - AWS Certificate Manager
I believe that means the Order would be marked valid assuming your config on AWS ACM is correct. It uses a CNAME record to store the needed value. This is the same format used by ACM for its free certs that are bound to an AWS service and are not exportable. For Route53 these CNAME are setup automatically during your config for this in ACM.
I did not see any mention of it supporting ACME ARI.
I'm curious to try it out but not sure if I'll get to that soon.
Looks like it’s layered pricing. $.50 cents after 1000 and $0.25 after 4000 certs in a month. That’s a lot. Do any of you issue 1000 public certs in a month ? I’m wondering why the tiers are at 1000 and 4000 certs and who uses so many. In our org, we use like 10.
Domain parkers, CDNs, and hosting providers have potentially millions of certs
It is not "certs", it is domain names. So two FQDN in one cert start at $2
A single wildcard entry starts at $5
I used the new AWS ACM ACME service. Not sure what I plan to do with it long-term but thought these comments useful.
ARI
I confirm there is no ARI support. This endpoint is not advertised in the directory
Testing
There is no test endpoint so each issued cert costs money.
New-Nonce
AWS ACME sets a response header of Content-Type: application/json even though there is no response data. Some json parsers may fail if you pass them an empty string. Certbot was not affected.
CSR algorithms must match
This caused me the largest grief. In short, in the CSR the public key algorithm and the digest signature algorithm must "match". Example: If your public key is 384 bit EC then the CSR signature must be ecdsa-with-SHA384 (type and bit size match).
Because of this I could not issue a P-384 cert using current Certbot. I could issue P-256. It seems the --elliptic-curve option for Certbot does not affect the CSR signature algo. This requirement also affected my custom client that is based on ACMECert. Google says acme.sh keeps these aligned but I did not test it.
The error if they do not match is like (w/value reflecting the mis-match):
EC P-384 key requires signing algorithm SHA384withECDSA
This algo matching requirement does not exist for other ACME CA like Let's Encrypt, Google Trust Services, or ZeroSSL as examples. Which is partly why it took me so long to understand exactly what it was complaining about. I don't think much about the CSR either so there's that too. I've submitted a support case to AWS about at least improving messaging or docs.
CSR public key algo must match ACM ACME Endpoint config
This is perhaps obvious but given the other algo issue it confused me. The message also seems more like an IAM policy restriction or similar which led me down some fruitless paths when the remedy was simple.
In the AWS ACM Console you setup an "endpoint" for ACME. In that you indicate the key type(s) for the cert. If your CSR public key algo does not match that selection it fails with a very long error something like:
User: arn:aws:sts::XXX:assumed-role/AcmAcmeIssuanceRole-XXX/acme-request-XXX is not authorized to perform: acm:RequestCertificate on resource: arn:aws:acm:RRR:XXX:certificate/* with an explicit deny in a resource-based policy
How obscure it is!