ietf-wg-acme

acme

Python2016–2019

ietf-wg-acme / acme · Archived

acme

A protocol for automating certificate issuance

Explore on GitHub Read Hacker News discussions

7Distinct people

8Mentions

0Explicit recommenders

938GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A protocol for automating certificate issuance

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2016-05-25 19:02:01 UTC to 2019-01-30 06:17:38 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	4	4
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	2
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1

What Hacker News says

8 sources

zjs·Jan 30, 2019

> TLS-SNI-01 and 02 were only disabled only a few weeks ago, and they haven't been officially removed from the ACME spec, ... Based on the repository's history, TLS-SNI-01 and TLS-SNI-02 appear to have been removed from the spec approximately a year ago: https://github.com/ietf-wg-acme/acme/commit/cfe118734bab3f6b...

In I exploited TLS-SNI-01 issuing Let's Encrypt SSL-certs for any domain (2018)

alwillis·Mar 14, 2018

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-... DNS security As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based

Read the rest

CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed. It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).

In ACME v2 and Wildcard Certificate Support is Live

alwillis·Mar 14, 2018

>Wow. A lot of sites are going to get owned. Why would you say such a thing? Tens of millions of certificates have been provisioned using the ACME protocol without issue. There’s a lot of cryptography behind the scenes that leads up to the TXT record being generated. You can read all about it at https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...

In ACME v2 and Wildcard Certificate Support is Live

yRetsyM·Jun 14, 2017

The blog post was a little vague on what the changes are to the standard. Found the repo were development is being managed: https://github.com/ietf-wg-acme/acme

In ACME v2 API Endpoint Coming January 2018

Intermernet·Aug 18, 2016

It looks like that should be happening soonish if I read the Github issues correctly. https://github.com/ietf-wg-acme/acme/pull/124 is "Enable the server to specify requirements for issuance" which seems to include wildcard cert support, but was only merged into master about 5 weeks ago. I presume further discussion is ongoing. Personally I'm glad that they're taking the time to get this right. They could have probably supported wildcard certs a while ago, but it would have been through some mangled and limited method. The method they're now looking at seems to be much more future proof. Of course, I may be completely wrong about this, but the above is what I gather from following the issues.

In Rate Limits

bburky·Jul 21, 2016

> The LE HTTP challenge gives no guarantee which A record it will use. That almost changed[0], but the current consensus[1] seems to be that you should be using dns-01 for validation behind a load balancer instead. [0] https://github.com/ietf-wg-acme/acme/pull/138 [1] https://mailarchive.ietf.org/arch/msg/acme/6RSxtvpkcQNPmKs9f...

In On the fly SSL registration and renewal inside Nginx with Let's Encrypt

pred_·Jun 11, 2016

You don't even have to specify an email address at all; it's considered optional in ACME.[0] [0] https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...

In Email Address Disclosures, Preliminary Report

michaelmior·May 25, 2016

This looks great! But hopefully as ACME[0] becomes popular there won't be a need for tools like this anymore. [0] https://github.com/ietf-wg-acme/acme/

In Show HN: TLS cert expiration dashboard