this post was submitted on 13 Jul 2023
42 points (100.0% liked)

Technology

37716 readers
341 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
alyaza@beehaw.org
TheRtRevKaiser@beehaw.org
gyrfalcon@beehaw.org
rs5th@beehaw.org
SemioticStandard@beehaw.org
TheRtRevKaiser@kbin.social
Los@beehaw.org
coldredlight@beehaw.org
remington@beehaw.org
42
Easy HTTPS for your private networks (www.getlocalcert.net)
submitted 1 year ago by trashhalo@beehaw.org to c/technology@beehaw.org
24 comments fedilink hide all child comments
 

This webpage provides instructions for using the acme-dns DNS challenge method with various ACME clients to obtain HTTPS certificates for private networks. Caddy, Traefik, cert-manager, acme.sh, LEGO and Certify The Web are listed as ACME clients that support acme-dns. For each client, configuration examples are provided that show how to set API credentials and other settings to use the acme-dns service at https://api.getlocalcert.net/api/v1/acme-dns-compat to obtain certificates. Interesting that so many ACME clients support the acme-dns service, providing an easy way to obtain HTTPS certificates for private networks.

HN https://news.ycombinator.com/item?id=36674224

seiferteric: Proposes an idea for automatically creating trusted certificates for new devices on a private network.

hartmel: Mentions SCEP which allows automatic certificate enrollment for network devices.

mananaysiempre: Thinks using EJBCA for this, as hartmel suggested, adds unnecessary complexity.

8organicbits: Describes a solution using getlocalcert which issues certificates for anonymous domain names.

austin-cheney: Has a solution using TypeScript that checks for existing certificates and creates them if needed, installing them in the OS and browser.

bruce511: Says automating the process is possible.

lolinder: Mentions Caddy will automatically create and manage certificates for local domains.

frfl: Uses Lego to get a Let's Encrypt certificate for a local network website using the DNS challenge.

donselaar: Recommends DANE which works well for private networks without a public CA, but lacks browser support.

you are viewing a single comment's thread
view the rest of the comments
[–] dan@upvote.au 10 points 1 year ago (1 children)

Because you might want to use HTTPS on a server that's not accessible externally. Some browser features only work over HTTPS.

[–] zergling_man@lemmy.perthchat.org 1 points 1 year ago (2 children)

Sounds like a bad browser.

[–] jarfil@beehaw.org 9 points 1 year ago* (last edited 1 year ago) (1 children)

Good browsers don't let random unauthenticated content to do whatever it wants on neither the local machine or the network.

HTTPS is also the only way to use client-side certificates for strong two-way authentication and zero-trust setups.

[–] zergling_man@lemmy.perthchat.org 1 points 1 year ago (1 children)

Good browsers don't let random unauthenticated content to do whatever it wants on neither the local machine or the network.

So, lynx?

zero-trust setups. private networks

[–] jarfil@beehaw.org 2 points 1 year ago

lynx, no-script... it's all fine until some web needs JavaScript yes or yes, which nowadays seem to be most of them, then it's a game of whom to trust.

Private networks are usually an oxymoron, they're only as private as far as the WiFi router or whoever clicks the wrong malicious link go. Zero-trust mitigates that, instead of blindly relying on perimeter defenses and trusting anyone who manages to bypass them.

[–] dan@upvote.au 1 points 1 year ago (1 children)

Every browser implements these limitations, as they're part of the web platform. Some examples are service workers, web crypto, HTTP/2, webcam, microphone, geolocation, and more. There's a list here: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts

[–] zergling_man@lemmy.perthchat.org 0 points 1 year ago (1 children)

Sounds like a bad browser.

[–] dan@upvote.au 2 points 1 year ago (1 children)

Every browser does this. It's intentional to push people towards using encrypted connections, especially for PII like geolocation.

[–] zergling_man@lemmy.perthchat.org 1 points 1 year ago

Sounds dystopian. I still won't feel bad for normies.