4 ms·
My point is, the clients are generally pretty bad despite the IETF spec. Lots of edge cases ignored, poor security practices. I understand the intention but t
by doublerebel 11y ago
My point is, the clients are generally pretty bad despite the IETF spec. Lots of edge cases ignored, poor security practices. I understand the intention but the effect is that the clients are just as opaque as the spec but often more incorrect. Who would try to launch a startup API for wide use without a Stripe-style spec these days?
Thanks for the advice, but it's not that I don't understand how to read it, it's that I can tell other devs don't understand it despite the good intentions of the authors.
Plenty of good clients are written for plenty of other tools, based on a much more straightforward call-and-response API spec. For example, the Hashicorp tools have a simple spec and proper clients in many languages.
- pfg 11y agoThe spec contains sample payloads for pretty much every resource. In fact, you can build a functional client for http-01 just by looking at the examples. On top of that, if you're using a programming language that's at least close to mainstream, there's a very good chance someone has already written a library which handles most of the nitty-gritty details of ACME. As an example, this is all the code you need with the acme-client ruby gem in order to solve a http-01 challenge and get a cert (slightly abbreviated): require 'acme/client' client = Acme::Client.new(private_key: private_key, endpoint: endpoint) registration = client.register(contact: 'mailto:contact@example.com') registration.agree_terms authorization = client.authorize(domain: 'example.org') # serve challenge.filename with content challenge.file_content challenge.request_verification # loop/sleep until challenge.verify_status == 'valid' csr = Acme::Client::CertificateRequest.new(names: ['example.org']) certificate = client.new_certificate(csr) # certificate.to_pem contains your signed cert. done!