from Hacker News

Automate Public Certificates Lifecycle Management via RFC 8555 (ACME)

by tvvocold on 4/12/22, 2:02 AM with 220 comments

  • by binwiederhier on 4/12/22, 2:46 AM

    That's great. Though maybe the title should acknowledge that it's only for Google Cloud customers.

    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.

  • by jiggawatts on 4/12/22, 4:34 AM

    The big benefit of ACME is that it verifies domain ownership at the correct level.

    DigiCert and the like will typically require domain verification at the TLD+1, which is meaningless gibberish that isn't even remotely an RFC standard. There's no such "concept" in DNS, which is intended to be delegated.

    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 insist 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.

    This kind of thing has happened to me repeatedly across both corporate and government projects. A 2-week project can have a 1 month delay added to it because of this.

    ACME gets it right, and nobody else does.

  • by yonran on 4/12/22, 4:24 AM

    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?

  • by woleium on 4/12/22, 3:43 AM

    Surely this is just google derisking an external dependency (letsencrypt), so they have full vertical integration, no?

  • by _yoqn on 4/12/22, 3:01 AM

    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.

  • by frankfrankfrank on 4/12/22, 11:58 AM

    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?

  • by alpb on 4/12/22, 6:19 AM

    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.

  • by vbezhenar on 4/12/22, 9:19 AM

    Another ACME alternative to letsencrypt is zerossl.

    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.

  • by theptip on 4/12/22, 6:14 AM

    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.

    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.)

    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.

  • by INTPenis on 4/12/22, 5:41 AM

    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.

  • by Tobu on 4/12/22, 2:24 PM

    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.

    https://www.rfc-editor.org/rfc/rfc8657.html

    https://pki.goog/repo/cps/4.7/GTS-CPS.pdf

  • by bogomipz on 4/12/22, 2:23 PM

    From the FAQ:

    >"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."

    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?

  • by egberts1 on 4/12/22, 8:50 AM

        Q: Do you offer certificates from a pure ECC based certificate chain?

    A: Not at this time.
    I see what you did there.

  • by PaywallBuster on 4/12/22, 4:56 AM

    Where can I see the rate limits?

  • by aaronchall on 4/12/22, 6:28 AM

    I recall stories of Google arbitrarily declaring users persona non grata, ruining the user's business and even their life, with no recourse.

    Is this another such risk vector?

  • by midrus on 4/12/22, 5:51 AM

    Wile E. Coyote will be so happy with this.

  • by jesprenj on 4/12/22, 5:17 AM

    > Do you issue certificates for punycode encoded Unicode domain names?

    > Not at this time.

    I thought punycode solved all integration issues and is meant to be backwards compatible ...

  • by robertwt7 on 4/12/22, 4:32 AM

    so it's only free for GCP customers..

  • by bruce511 on 4/12/22, 3:19 AM

    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?

    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?

  • by steveneo on 4/12/22, 3:08 AM

    When google announces a new product, the first thing I think about is always when that product will be shut down.

  • by acutesoftware on 4/12/22, 3:07 AM

    That's great, and I am sure it is cool, but I don't trust Google to keep products maintained any more.

    I won't be trying it out.

  • by lanbanger on 4/12/22, 5:04 AM

    April 2023: Google announces end of free ACME server

  • by Zhenya on 4/12/22, 4:25 AM

    Is this free like custom domain for gmail free?

    yeesh

  • by elcomet on 4/12/22, 7:43 AM

    Previous title was much better @dang

  • by vmception on 4/12/22, 3:02 AM

    Double dare you to use and rely on that

  • by JoachimS on 4/12/22, 9:10 AM

    Will it bring in advertising dough?

    If not, possibly reserve a spot here: https://killedbygoogle.com/

  • by miked85 on 4/12/22, 6:27 AM

    It really would be a mistake to trust your business with a Google product in general, especially a "free" one.

  • by _nickwhite on 4/12/22, 3:14 AM

    Sorry, you’re too late. Already discontinued.

    Obviously kidding! Glad to see this brought online for GCP customers.

  • by upsidesinclude on 4/12/22, 3:57 AM

    "FREE"

  • by alfiedotwtf on 4/12/22, 3:30 AM

    I found this article via Google Reader

  • by midjji on 4/12/22, 6:22 AM

    "Free"

  • by paxys on 4/12/22, 3:04 AM

    *For Google Cloud customers. Not exactly "free" when you are required to pay into the ecosystem.

  • by ck2 on 4/12/22, 5:00 AM

    Would that be like the "free for life" google gsuite accounts that are ending next month?

    Do not rely on any "free" google product you aren't willing to pay for.