#smallstepca — Public Fediverse posts

NEW BLOGPOST!

It's been a while! Very happy to share this mTLS in-depth tutorial. Lots of subjects in this one: password managers, TLS, mTLS of course, @traefik, @bitwarden, @vaultwarden_releases, Smallstep's CLI...

https://zoug.fr/mtls-bitwarden-vaultwarden-traefik-smallstep/

Don't hesitate to reply to this post: it'll help me test that the comments section works fine (and I'd greatly appreciate some feedback :))

#mtls #https #tls #passwordmanager #password #bitwarden #vaultwarden #traefik #smallstepca

Inspired by @jwildeboer I spent the evening learning all about #smallstepca and getting a nix module working with support for my web and mail services. I crossed a threshold of comprehension where the role of the step-ca server, the cli client, and Provisioners clicked into place.

The key insight is that the server is an API for frequent certificate operations, like renewal, with limits and templates for a provisioner. I am still using a mental model of long lived certificates, after decades of dealing with them and the fallout of expiry and failed renewal in a context where one has not automated so much of the certificate lifecycle.

I still get a bit alarmed at the thought of 16 hr effective lifetimes of certificates, combined with refusal to renew after expiry. Having to re-provision so many certs and having the CA be a point of failure for all your communications seems like a big risk for questionable gains.

It also means entire communication fabrics freezing or falling apart if a CA is attacked or simply bitrots away, or a critical comms path is shut down for an extended period.

Perhaps these worries will dissipate once I learn more about provisioning tokens and hope to make onboarding and issuing new certs trivial.

I want this to be easy enough for the equivalent of an enthusiast to operate like they would a network file share or other consumer grade home computing infrastructure.

Kudos to the smallstep team and others who have advanced the state of this art.

#ayuda fediverso #SmallStepCA #NginxProxyManager

como se hace, sin morir en el intento, de que los ceritificados o bien:
- duren mas de un puto dia
- hacer el auto renew por #acme

estoy intentando seguir
https://smallstep.com/practical-zero-trust/nginx-tls
https://smallstep.com/docs/tutorials/acme-protocol-acme-clients/index.html#popular-acme-clients

pero me viene un poco grande por ahora

nginxproxymanager con letsencrypt = chupado. pero estoy con dominios locales y claro, si letsencrypt no ve el dominio, tururu

y no, no quiero hacer la chapuza de exponer el servicio a internet cuando toque renovar

quiero un CA propio (lo tengo) smallstepCA, y quiero que mi reverse proxy me auto renueve, o que los certificados me duren mas de un misero dia.

me sale esto "The request was forbidden by the certificate authority: requested duration of 8760h1m0s is more than the authorized maximum certificate duration of 24h1m0s." por mucho que en mi ca.json ponga ""maxCertDuration": "8760h","

y no se como exponer mi CA para que acme funcione

esta direccion: https://ca.lab.local/.well-known/acme-directory

no me va, me sale siempre en el CA
http: TLS handshake error from 192.168.1.128:58926: local error: tls: bad record MAC

en nginxproxymanager en advanced configuration puse:

location /.well-known/acme/ {
proxy_pass https://192.168.1.155/acme/acme/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}

y en mi dns (technitum) puse de forma que ca.lab.local vaya a mi reverse proxy claro esta

pero no importa que lo ponga en puerto 80 (con el insecure port en ca.json
"insecureAddress": ":80"
con o sin certificado
con o sin ssl forzado
con o sin block exploits...

CREO haber probado todas las putas combinaciones posibles, me sale el puto mensaje TLS handshake error from 192.168.1.128:58926: local error: tls: bad record MAC

se agradece #boost

@sam @matiargs @z3r0