That's great. Though maybe the title should acknowledge that it's only for Google Cloud customers.<p>It's also quite odd that the article doesn't mention Let's Encrypt or the ISRG at all. I would have expected some sort of acknowledgement to their fantastic work over the years.
The big benefit of ACME is that it verifies domain ownership at the correct level.<p>DigiCert and the like will typically require domain verification at the TLD+1, which is <i>meaningless gibberish</i> that isn't even remotely an RFC standard. There's no such "concept" in DNS, which is intended to be <i>delegated</i>.<p>So for example if I'm tasked with deploying a web app to "dev1.app.project.org.parentcompany.megacorp.co.uk" where the "project team" is based out of -- say -- Australia, then DigiCert will <i>insist</i> that I verify that I own "megacorp.co.uk", which... I don't. The parent company might not either. MegaCorp's UK head office does. They've never heard of me, and it'll take me a month to get through to someone who cares about my tiny, outsourced project down under.<p>This kind of thing has happened to me <i>repeatedly</i> across both corporate and government projects. A 2-week project can have a 1 month delay added to it because of this.<p>ACME gets it right, and nobody else does.
How do these certificates compare against letsencrypt on the technical dimensions? e.g. certificate chain size, rate limits, whether every certificate is published to the certificate transparency logs, what OSs the root CAs are compatible with?
Who would trust Google with their infrastructure these days anyway? Personally I do need to work with Google services occasionally but always experience default anxiety about it.
Speaking of which; is anyone else old enough to remember when it was discovered that all (Root) Certificate Authorities were compromised by the 5+1 eyes?
One major problem with Google’s L7 load balancers is that the config changes take 5-20 mins to take effect. So google trying to set up an ACME challenge on a LB, solving it, and setting the managed TLS cert on it can take non-negligible time (15-30 mins?). I hope this gets fixed someday.
Another ACME alternative to letsencrypt is zerossl.<p>It's especially great because letsencrypt is operated by US company ISRG and zerossl seems to be from Austria, so if you're not happy with your server being dependant on US, it might be a good option.
This is great news. One limitation with Lets Encrypt is their rate limits are a bit low for Review Apps - you can’t issue more than 50 certs a week under a given domain.<p>So if you’re spinning up tens or hundreds of review apps per day, you can’t get a fresh cert for each, and so you need to do something different than your production environment does. (A wildcard cert is the obvious choice.)<p>I hope this offering has a high enough quota that you can get enough certs to do review apps properly; the marginal cost to Google per customer is probably negligible, whereas LetsEncrypt doesn’t have other revenue generating offerings they can use to cover their operating costs.
We've had an internal ACME server at my dayjob for over a year now. It's one of the few things I'm proud of where we really got out early on a cool technology. Otherweise we're a big telco and move like a oil tanker.
Any status for RFC 8657, ACME CAA support? This is for restricting which account and which validation methods may issue certificates. The CPS says they may use it, which is too vague and I'm not going to test it right now.<p><a href="https://www.rfc-editor.org/rfc/rfc8657.html" rel="nofollow">https://www.rfc-editor.org/rfc/rfc8657.html</a><p><a href="https://pki.goog/repo/cps/4.7/GTS-CPS.pdf" rel="nofollow">https://pki.goog/repo/cps/4.7/GTS-CPS.pdf</a>
From the FAQ:<p>>"Each of these have different scenarios where their use makes the most sense, for example TLS-ALPN-01 might make sense in cases where HTTPS is not used and the requestor does not have access to dynamically update DNS records."<p>I'm confused by TLS-ALPN-01. I understand the idea of using certs for domain verification but if there is no TLS in use how does the client verify this after the cert has been issued exactly?
I recall stories of Google arbitrarily declaring users persona non grata, ruining the user's business and even their life, with no recourse.<p>Is this another such risk vector?
> Do you issue certificates for punycode encoded Unicode domain names?<p>> Not at this time.<p>I thought punycode solved all integration issues and is meant to be backwards compatible ...
The article has been on HN for an hour. It has 8 comments, 5 of which were my first thought - why on earth would you expect this service to hang around, based on Google's track record?<p>Wether it lasts or not, this surely has to be an issue for Google innovations going forward? If the perception is that any new thing will die, especially not-consumer-scale things, then how do they build traction?
Will it bring in advertising dough?<p>If not, possibly reserve a spot here:
<a href="https://killedbygoogle.com/" rel="nofollow">https://killedbygoogle.com/</a>
Would that be like the "free for life" google gsuite accounts that are ending next month?<p>Do not rely on any "free" google product you aren't willing to pay for.