HTTPS su un IP privato: identità del certificato o nome host?
Un IP privato può essere un’identità TLS valida se il certificato lo dichiara. Scegliete tra una SAN IP e un nome host stabile, poi pianificate il cambio di indirizzo.
Il vostro servizio su https://10.60.0.25 può avere TLS autenticato anche senza un nome DNS. L’indirizzo è l’identità che il client deve convalidare, e il certificato deve descriverla esattamente. La decisione è se quell’indirizzo è abbastanza stabile da essere un’identità, o se un nome host sarebbe più facile da mantenere. La VPN risponde alla raggiungibilità; non risponde a questo.
Se identità e fiducia sono corrette, un URL basato su IP è una progettazione legittima.
Che cosa convalida davvero il client
Il client confronta l’identità di riferimento nell’URL con i nomi alternativi del soggetto del certificato. Per un indirizzo IP, ciò significa una voce iPAddress uguale all’indirizzo. Un nome comune amichevole non è un sostituto.
RFC 9525 separa le identità di indirizzo IP dai nomi DNS e definisce la regola di corrispondenza. Mettere l’indirizzo solo nell’etichetta del soggetto, o come voce di tipo DNS, non produce alcuna corrispondenza. Per questo la SAN è il campo da ispezionare quando appare un avviso.
La fiducia è un secondo controllo indipendente. Una corrispondenza di nome non corregge una catena non attendibile, un certificato scaduto o un certificato rilasciato per un altro scopo.
Decisione uno: l’indirizzo è abbastanza stabile da essere un’identità
Se l’indirizzo è fisso per tutta la vita della distribuzione, un certificato SAN IP è semplice e onesto. Se il servizio può spostarsi, ogni spostamento diventa una sostituzione del certificato e un aggiornamento coordinato dei client.
Un nome host stabile riduce questo accoppiamento. I client usano il nome, il DNS approvato lo mappa all’indirizzo corrente, e un cambio di indirizzo smette di essere un cambio di identità. Il certificato necessita ancora di rinnovo, ma l’URL non cambia.
Una voce gestita nel file hosts può fornire la mappatura in un ambiente piccolo. Aggiunge una responsabilità di distribuzione; non sostituisce la verifica TLS.
Decisione due: come il client si fiderà dell’emittente
Per una CA privata, distribuite l’ancora di fiducia ai dispositivi previsti tramite un meccanismo approvato. Non abituate gli utenti a ignorare gli avvisi o a installare un certificato consegnato da una pagina di accesso. Se volete un certificato pubblico, verificate le regole attuali dell’emittente per gli indirizzi privati prima di pianificare su di esso. La maggior parte degli emittenti pubblici non convaliderà un IP privato come identità pubblica.
Esaminate il browser o l’applicazione reale. Il suo archivio di fiducia e il suo comportamento di convalida contano più della documentazione generale sui certificati del sistema operativo. Verificatelo sul dispositivo reale, non solo nella console.
Il gateway VPN potrebbe non essere la macchina che esegue l’applicazione web, quindi non presupponete che il certificato del tunnel abbia qualcosa a che fare con questo.
Pianificate il cambio di indirizzo prima che avvenga
Se 10.60.0.25 diventa 10.60.0.40, il vecchio certificato non descrive più l’URL. Pianificate la sostituzione e l’aggiornamento dei client insieme, e non disattivate mai la verifica durante lo spostamento.
Scegliete l’identità che gli utenti digiteranno o che le applicazioni configureranno, poi allineate rilascio, fiducia, distribuzione e rinnovo attorno ad essa. Una pagina raggiungibile con un avviso ignorato non è lo stesso risultato di un servizio di cui il client verifica l’identità.