101–110 of 126 posts
It's just as easy to deploy a trusted CA using MDM as it is to deploy this.
This leverages the ACME DNS server which has a REST API: * https://github.com/joohoi/acme-dns If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel: * https://github.com/AnalogJ/lexicon * https://pypi.org/project/dns-lexicon/ * https://dns-lexicon.readthedocs.io/en/latest/user_guide.html
It's inspired by ACME DNS, but getlocalcert is actually using PowerDNS with a Django API that's compatible. I originally built the tool as a fork of acme-dns, but lost traction somewhere, I switched to pdns and it worked great.
This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…
Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.
Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted.
And with an actual trusted CA the trust is way too wide (every domain).
Not to mention revocation lists and certificate renewals (and revocation s) ...
Dedicated letsencrypt "internal" domain is probably the sweetspot for most uses these days.
Maybe a serviceN.int.example.com where int.example.com allows for dynamic DNS updates/DNS challenges.
I've been thinking about setting up powerdns/coredns/knotdns with rfc dynamic updates for a dedicated internal domain - but for now tailscale with magic DNS mostly fills the need (unfortunately not with ssl for all k8s internal services, "only" VPN).
I wrote about that here:
https://blog.katarismo.com/2023-06-04-expose-any-private-ser...
All my internal and external services inside and outside of my headscale/tailscale network can use a single cert this way. I generate a single cert and then reuse it everywhere.
The whole point of a local DNS and local CA though is to insulate yourself from cloud expenses and failures. Our DNS system has had 0 outages, whereas our Google Fiber uplink has aprox one failure a month (Weather, construction, maintenance, upgrades, unscheduled outages). It's just as easy to deploy a trusted CA using MDM as it is to deploy this.
Re. MDM, I've never seen a perfect rollout.
- Setup Tailscale on the server and personal device
- Deploy apps (self hosted tools that I use) on the wireguard interface created by Tailscale
- Deploy caddy as a reverse proxy for all these tools and use `.internal` domain
- Use Adguard's DNS rewrites feature to answer custom DNS response for specified `.internal` domains. The A record contains the IP assigned by Tailscale (wg0 interface) for that device.
The Caddyfile is as simple as:
http://miniflux.karan.internal {
reverse_proxy 127.0.0.1:3000
}
Earlier quoted context omitted.
Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.
> all you have to do is find the root CA it generates and install it on your devices. Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted. And with an actual trusted CA the trust is way too wide (every domain). Not to mention revocation lists and certificate renewals (and revocation s) ... Dedicated letsencry…
https://github.com/joohoi/acme-dns/
https://docs.getlocalcert.net/tips/validation-domain/#self-h...
Earlier quoted context omitted.
We setup each project with it's own subdomain... so a /etc/hosts file would be something like 127.0.0.1 client7.companyname.dev our-amazing-product.companyname.dev postgres2.companyname.dev So, then we can use the same settings, etc across devs. Then each dev just runs the script to renew the script as they are needed (no need to share certs between devs)
Why not put project.companyname.dev in DNS? (Pointing to 127.0.0.1, ::1?)
The web/cloud world is so much nonsense. First, why do you even need HTTPS on a trusted network. Also if you want a trusted network, why not just use IPSec? HTTPS was specifically built to work over the Internet because it was too hard to switch from IPv4. Second, if it's private, surely you can just use your own Certificate Authority, instead of paying a tax to be listed on someone else's Certificate Authority.
trick question: you can't
even the network links between hosts in a single rack in a DC can be vulnerable
* own CA, to be distributed to all systems via Ansible playbook or Dockerfile directives
* Hashicorp Vault with enabled PKI engine
* Ansible Hashivault module [1]
* Ansible role & playbook to tie it all together
* CI enviroment for automated deployment of SSL certs to target systems
Works flawlessly once set up, including restart/reload of affected services. Might do a writeup on my personal blog at some point.
[1] https://github.com/ansible-collections/community.hashi_vault