Non esiste un interruttore HTTPS globale confermato per ogni app
La discussione della community non ha individuato un pulsante di ZimaOS che assegni automaticamente a ogni applicazione installata un endpoint HTTPS valido. Ogni app può essere in ascolto su una porta diversa, utilizzare funzionalità web differenti e richiedere regole di instradamento separate.
L'utente accedeva allo spazio di archiviazione tramite un dominio e un IP pubblico statico, ma continuava a ricevere un avviso relativo alla connessione non sicura. Il solo nome di dominio non crea TLS. Il browser deve raggiungere un endpoint che presenti un certificato valido per quel nome host.
Inizia elencando ogni app, la relativa porta interna, il nome host che vuoi utilizzare e specificando se l'accesso sarà solo locale, remoto privato o tramite Internet pubblico. Questo ambito determina il design di ingresso corretto.
Scegli un solo modello di ingresso per l'obiettivo di accesso effettivo
Un proxy inverso può terminare TLS sulla porta 443 e instradare nomi host diversi verso porte interne separate delle app. Questa soluzione è adatta a un design basato sui domini, in cui un unico frontend controllato serve più applicazioni.
Un tunnel gestito può fornire un punto di ingresso HTTPS senza inoltrare direttamente ogni porta delle applicazioni dal router. Un overlay privato come Tailscale risolve un problema diverso: i dispositivi autenticati entrano in una rete privata e possono raggiungere i servizi senza renderli generalmente pubblici.
Scegli un modello prima di configurare i certificati. Sovrapporre il port forwarding diretto, un tunnel e un overlay senza una motivazione definita aumenta il numero di percorsi da proteggere e sottoporre a debug.
I certificati appartengono al punto di terminazione TLS
Un certificato Let's Encrypt può essere utilizzato da un proxy inverso o da un altro servizio che controlla la connessione HTTPS. Non viene installato “sul dominio” e ottenerne uno non insegna automaticamente a ogni app backend come utilizzarlo.
Associa un nome host al proxy o al tunnel scelto, emetti o collega il certificato in quel punto e instrada quel nome host verso un'app interna. Mantieni privata la porta backend, salvo che l'architettura richieda specificamente l'accesso diretto.
Se il browser mostra un avviso, controlla il nome host indicato nel certificato, la destinazione DNS, la catena del certificato e il componente che risponde effettivamente sulla porta 443. Non ignorare l'avviso come soluzione permanente.
Convalida un'applicazione prima di ripetere lo schema
Verifica l'accesso, i caricamenti, i download, gli aggiornamenti in tempo reale e tutte le funzionalità che dipendono dai websocket tramite il nome host HTTPS. Una pagina che si carica ma non consente di caricare file o mantenere una sessione non è configurata completamente.
Riavvia il proxy o il tunnel e l'app di destinazione, quindi ripeti lo stesso flusso di lavoro. Conferma che HTTP venga reindirizzato solo dove previsto e che le porte backend grezze non siano esposte involontariamente a Internet.
Quando un'app funziona, ripeti la mappatura nome host-backend per quella successiva. Se un servizio ha requisiti particolari per il proxy, annulla solo la route che presenta problemi invece di smantellare gli endpoint HTTPS funzionanti.
L'HTTPS remoto non sostituisce il controllo degli accessi
TLS crittografa il traffico e autentica il nome host, ma non decide chi debba utilizzare l'applicazione. Mantieni attivi una solida autenticazione dell'app, un'esposizione limitata, gli aggiornamenti e i registri di audit.
La discussione consiglia di approfondire Cloudflare Tunnels, Tailscale o un proxy inverso come Caddy, ma non documenta un'implementazione completata. Si tratta di indicazioni architetturali, non di una procedura dettagliata per ZimaOS confermata dalla fonte.
Interrompi la procedura prima dell'esposizione pubblica se il metodo scelto, la gestione del certificato o il confine di autenticazione non sono chiari. Esegui prima la convalida su un servizio non critico oppure utilizza l'accesso remoto privato mentre progetti il percorso pubblico.
Domande frequenti
Un unico certificato può proteggere automaticamente ogni app di ZimaOS?
Non da solo. Un proxy o un altro endpoint TLS deve comunque disporre di un nome host e di una regola di instradamento per ogni servizio backend.
Devo esporre la porta di ogni app per l'HTTPS remoto?
Non necessariamente. I proxy inversi e i tunnel gestiti sono progettati per centralizzare l'ingresso, mentre gli overlay privati evitano l'esposizione pubblica generale.
Tailscale è la stessa cosa di un proxy inverso?
No. Tailscale crea una raggiungibilità di rete privata tra dispositivi autorizzati; un proxy inverso accetta richieste web e instrada i nomi host verso i servizi backend.
