PKI interna e rotazione mTLS

Scope

La PKI interna protegge i collegamenti east-west gia' trasportati su Tailscale:

• backend verso PgBouncer/PostgreSQL;
• PgBouncer verso PostgreSQL;
• backend, worker e bridge verso NATS;
• Kamailio htable sync verso PostgreSQL e NATS.

Kamailio verso FreeSWITCH ESL resta escluso per ADR-0011: ESL e gateway sono su loopback dello stesso host.

Deploy iniziale

1. Eseguire infra/playbooks/deploy_pki.yml su management.
2. Salvare offline fingerprint root CA e materiale di recovery di step-ca.
3. Popolare vault_pki_step_ca_fingerprint con il fingerprint root CA.
4. Eseguire infra/playbooks/deploy_stateful.yml, deploy_signaling.yml e deploy_management.yml per emettere i certificati dei servizi.

La CA ascolta su Tailscale e rilascia certificati annuali. I client installano /etc/akira/certs/ca.crt e i propri {service}.crt/.key.

Renew ordinario

Ogni host installa /usr/local/sbin/akira-cert-renew, schedulato via cron alle 03:17. Il renew parte quando il certificato scade entro 30 giorni.

Verifica manuale:

sudo /usr/local/sbin/akira-cert-renew
sudo step certificate inspect /etc/akira/certs/backend.crt --short

Dopo un renew server-side riavviare il servizio che legge il certificato a startup, per esempio pgbouncer, postgresql@16-main o il compose NATS.

Rotazione CA

1. Creare nuova intermediate CA da step-ca mantenendo la root offline.
2. Distribuire il nuovo bundle CA in /etc/akira/certs/ca.crt.
3. Rieseguire i playbook con tag pki per emettere nuovi leaf certificate.
4. Riavviare Postgres, PgBouncer, NATS e i client Python.
5. Revocare la vecchia intermediate quando tutti i leaf sono migrati.

Failure mode

Se un certificato scade, i client mTLS falliscono la connessione. Le soglie operative sono alert a 30 e 7 giorni, piu' renew giornaliero. In emergenza:

sudo step ca renew --force /etc/akira/certs/<service>.crt /etc/akira/certs/<service>.key
sudo systemctl restart <service>