# TLS per DWH REST La chiave DWH è accettabile solo sopra TLS verificato. Un errore `401` o `503` non autorizza mai a ridurre la verifica del certificato. ## Stato PSD L'origine REST PSD corrente usa il certificato self-issued/private di Nginx. Il SAN copre `supabase-aritmolab.policlinicosandonato.it`, l'origine `.it` approvata, e non copre un dominio `.com`. Non usare `.com` finché non è incluso esplicitamente nel SAN. Chi non dispone già di trust equivalente approvato riceve la CA separatamente e configura `TLS_CA_FILE`. La CA non è una credenziale, ma la sua integrità è un confine di sicurezza: fuori da Git e non scrivibile da utenti non autorizzati. ## Fingerprint fuori banda Calcolare localmente il fingerprint del file ricevuto: ```bash openssl x509 -noout -fingerprint -sha256 -in /absolute/protected/psd-dwh-ca.pem ``` Confrontarlo con il responsabile autorizzato tramite un canale indipendente dalla consegna (vault aziendale o canale telefonico verificato). Nell'evidenza registrare solo conferma, approvatore e timestamp; mai corpo certificato, fingerprint completo o output grezzo. ## Binding e ping Il binding headless PSD effettivo è: ```dotenv THT_WS_PSD_CLINICAL_DWH_TLS_CA_FILE=/run/secrets/psd-clinical-dwh-ca.pem ``` Il file sorgente locale è collegato da file operatore non tracciato. Usare URL `.it`, poi **Test connections** su `/rpc/ping`. Non disabilitare TLS e non usare `curl -k`. ## Rinnovo coordinato 1. Preparare certificato e chain nuovi; verificare prima SAN `.it` e assenza di falsa copertura `.com`. 2. Confermare fuori banda il nuovo fingerprint. 3. Consegnare la CA/chain nuova ai client con `TLS_CA_FILE`, senza rimuovere ancora la precedente. 4. Aggiornare vault/binding e verificare ping con TLS normale. 5. Solo con gate Nginx approvato installare il certificato server e ripetere il ping. 6. Ritirare il trust precedente dopo la finestra approvata. Il rinnovo non modifica chiavi `dwh-auth`, record o ruoli PostgreSQL. TLS e rollback della route restano approvazioni e backup distinti.