2 ms·
On k8s, there's cert-manager but also you need k8s... Most browsers support trust on first use for leaf certs
by nijave 3mo ago
On k8s, there's cert-manager but also you need k8s...
Most browsers support trust on first use for leaf certs
- jmbwell 3mo agoI guess I mean treat it as a clear first class feature. Right now most browsers treat it as an arcane error. I’m thinking more “This is the first time you’re connecting to this site. Do you trust it?” And later if something changes, then they can do the whole DOING SOMETHING NASTY! thing, which is effectively the experience today
- nijave 3mo agoYeah, that's fair. I think they're optimized for non technical users without a decent escape hatch.
- notTooFarGone 3mo agoFirefox now started that you can't even go on the page on some occasions. Using a browser in an air gapped environment is so much more pain than it should be.
- zufallsheld 3mo agoWell, if your cert-manager distributes its own CA, you'd still need the clients to trust the CA, even in k8s.
- nijave 3mo agoTrue but you can have cert-manager issue public certs then create service accounts for off cluster things to be able to pull the cert from the Secret so k8s+cert-manager acts as a local broker that handles renewal. You can also invert and have k8s cronjobs provision the generated certs into other infra With this setup, you don't have to worry about the RHEL certbot snap updating to a broken version which gets blocked by SELinux...
- bigfatkitten 3mo agoThat support is limited. Browsers refuse to support passkeys when you TOFU untrusted certs, and for good reason.