Other Authentication Methods


#21

It looks like Caddy should support it in the next release:

And lego is easy to use (I think).


#22

Cloudflare DNS is free, at least for personal use. Nothing to pay there. But yes, you do need to have a domain.

Can this notional user set a CNAME record? Then use acme-dns with the server at auth.acme-dns.io.


#23

This looks interesting and supports Windows too.
Can’t wait for 0.12!

Not sure if you can fit a lego into a rasPi - LOL
I don’t know the minimal requirements for lego - will have to research that. Thanks.


#24

I don’t know. It looks like compressed binaries are 6-7 MB. I hope it doesn’t take much memory to run. I bet it’s probably doable in most environments.


#25

Domains have annual costs but this does come closer to covering all users.
Perhaps using a free (totally insecure) domain via CF DNS to get a secure cert your free site is worth it for some - but definitely not for me.
[I won’t even mention anything further for fear of promoting insecure systems]


#26

Sooner than you’ll get a new proposed method adopted into the ACME draft standard and coded into Boulder, I’d wager.


#27

By the way, the “official” place to discuss this (although it’s on-topic for this forum) is over in the IETF ACME WG

https://datatracker.ietf.org/wg/acme/charter/

which has a public mailing list that you can join.

The people there are probably very skeptical but very interested in this topic.

Personally, I’d like to see a DNS registrar challenge method, where a DNS registrar could be contacted by an ACME CA and confirm that a particular ACME account key should be authorized to issue certificates for a domain, kind of akin to the CAA ACME account limitation, but for the positive assertion rather than the negative assertion.


#28

The answer to this lies in DNS.
DNS authentication proves domain ownership and allows DV certs to be issued.
The problem is the current DNS auth system requires an immediate change in DNS (and that auth will not last more than 30 days).
We need a push for a method that involves a single permanent DNS entry (which can be checked on every issuance - but would not need to ever be changed again.)
It could even allow for multiple controlling entries.
The client makes the request and presents his ID (account #).
LE checks if that ID is allowed in the zone and is properly signed via DNSSEC.
Passing such a validation should be sufficient proof.


#29

I can see how this may seem like a “slippery slope” that ends with… less LE certs.
Because the next logical progression may cut out the “middle man” and have DNSSEC validate the public cert.
That is, if DNSSEC can prove ownership to a CA, why can’t it prove ownership to everyone?
Simply create a self-signed cert and publish the DNSSEC signed public cert into your DNS zone.
Cert holder = domain holder.

and we can all move onwards with encrypting the rest of the Internet…


#30

Ryan Sleevi has already debated this possibility at some length with other people advocating it, so you might want to take a look at those archives (maybe on mozilla.dev.security.policy?).


#31

Here, I suggest looking at


#32

I can’t seem to find much on that exact topic…
Do you recall the outcome of that debate? (was their a consensus?)


#33

One debate was

https://cabforum.org/pipermail/public/2016-September/008328.html

and I think there are others.


#34

I’d like to know under what methods Amazon CA (CloudFront) has been operating all this time, because my certificates with them auto-renew yearly, and the only validation I performed was setting a couple of CNAMEs a number of years ago. (and I’m not using Route53 for DNS).

Some of the objections I’ve read seem to fly in the face of active CA practices, but it’s pretty opaque to judge from the outside so I’m probably misinterpreting.


#35

I don’t know real details, but their DNS validation is equivalent to the ACME ‘assisted-dns-01’ proposal, which generally seems to be considered to follow the letter of the BRs, but arguably not the spirit of them.

https://www.ietf.org/mail-archive/web/acme/current/msg02525.html

E.g. to validate s3.mnrd.us I created a CNAME record called _c8afe770ef182b071eb9ddbc7b57b104.s3.mnrd.us pointing to _b53c377e57af204232905069909dfb09.acm-validations.aws. It’s a dynamic TXT record which just so happens to be in a domain hosted by the CA.

_c8afe770ef182b071eb9ddbc7b57b104.s3.mnrd.us.           3600  IN  CNAME  _b53c377e57af204232905069909dfb09.acm-validations.aws.
_b53c377e57af204232905069909dfb09.acm-validations.aws.  10    IN  TXT    "d9e5665f6c29438bb4b932119c8f54af"

On top of that, they implement some sort of nebulous “HTTPS validation” for renewals. Since the certificates are only used on AWS-controlled web servers, it would be easy to implement something like HTTP-01 or TLS-ALPN-01 invisibly to customers.

https://docs.aws.amazon.com/acm/latest/userguide/how-domain-validation-works.html

Edit: I don’t know which of the ten blessed methods they use or how they interpret the BRs, but the general idea can be guessed…


#36

Yeah.

ACM automatically renews ACM Certificates that you validated by using DNS. ACM renews each certificate before it expires as long as the certificate is in use and the DNS record is in place.

Reading this in the ACM docs makes my blood boil, ngl. Being able to do the same in ACME would be like solving world hunger. But you make a good point that they do not allow certificate export, so the reasoning may be different.


#37

Let’s Encrypt will be at a disadvantage unless Let’s Encrypt Web Services Inc takes over the world and runs everyone’s servers. :slightly_frowning_face:


closed #38

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.