Ho bisogno di un certificato SSL separato per un reindirizzamento DNS?


17

Sto implementando un'applicazione multi-tenant in cui la mia applicazione ospita e serve documentazione tecnica per il prodotto di un inquilino.

Ora, l'approccio che mi stava prendendo in considerazione era - ho ospitare la documentazione in docs.<tenant>.mycompany.come chiedo al mio inquilino di impostare un record CNAME DNS per puntare docs.tenantcompany.coma docs.<tenant>.mycompany.com.

Voglio che il sito sia abilitato per SSL con il certificato del mio inquilino. Volevo capire se la mia azienda tenant ha un certificato SSL con caratteri jolly, funzionerà con questa configurazione o dovrà essere acquistato un nuovo certificato SSL docs.tenantcompany.com?


Solo per chiarire, hai un jolly per * .mycompany.com?
zymhan,

@WildVelociraptor sì, ho un certificato SSL jolly per*.mycompany.com
codematix

@codematix A scanso di equivoci, un certificato jolly per *.example.com non corrisponderà docs.tenantname.example.com ! Il carattere jolly è valido solo per un "sottodominio"; essa corrisponderà docs-tenantname.example.com , per esempio. L'S3 di Amazon ne è un buon esempio: il *.s3.amazonaws.comcertificato fallisce quando si accede a un bucket con un punto, come www.example.com(che finisce con un nome host come www.example.com.s3.amazonaws.com); tali nomi bucket sono richiesti per l'hosting web S3.
Calrion,

Si noti che l'uso di un cname che punta al proprio server significa che è possibile evitare la necessità di un certificato fornito dall'inquilino. Alcuni provider di certificati (incluso letsencrypt.org ) supportano la convalida della proprietà del dominio tramite https. Per quanto riguarda le migliori pratiche di sicurezza, questo approccio è di gran lunga superiore (già discusso nel serverfault.com/a/765957/4480 ). È consentito consentire all'inquilino di fornire il proprio certificato (sebbene generarlo da soli sia più semplice per l'inquilino), ma NON devono fornire un certificato con caratteri jolly.
Brian,

Risposte:


39

Il nome del certificato deve corrispondere a ciò che l'utente ha inserito nel browser, non al record DNS "finale". Se l'utente inserisce, il docs.tenantcompany.comtuo certificato SSL deve coprirlo.

Se docs.tenantcompany.comè un CNAME per foo.example.comil certificato non non ha bisogno di copertura foo.example.com, solo docs.tenantcompany.com.


25

La risposta di Jason è corretta. Ma solo per chiarire un po 'i termini qui, "Reindirizzamento DNS" è un po' un termine improprio. DNS ha record CNAME (alias alias) che è un nome che punta a un altro nome. Ma non è un reindirizzamento. La traduzione da nome a nome in IP avviene tutto in background e il tuo browser si preoccupa solo del nome iniziale.

L'unica cosa che reindirizza sono i server Web in cui il server dice esplicitamente al tuo browser di andare altrove. Se il tuo server web stava effettivamente effettuando un reindirizzamento sull'altro nome, avresti effettivamente bisogno di certificati per entrambi i nomi perché il tuo browser alla fine si sarebbe connesso a entrambi separatamente.


2
grazie per avermi corretto. Hai ragione, non è il reindirizzamento ma l'alias CNAME.
codematix,

Il mio client ha un Server Adominio example.com. Ho creato un sito Web per lui e mantenuto il sito in Server B. Il mio client ha configurato il suo DNS A Recordche punta dog.example.comall'indirizzo IP del mio server Server B. Ora il mio client sta ottenendo SSL per dog.example.com. La mia domanda è: il mio cliente deve darmi la certificazione SSL da inserire Server B? O deve solo inserirlo Server A? O cos'altro dovremmo fare? Siamo entrambi confusi su questo, grazie!
user2875289

1
Se il record A dog.example.comindica direttamente l'IP del tuo server, allora sì. Il tuo server deve contenere il certificato e la chiave privata per quel nome. Il server A nel tuo esempio è irrilevante.
Ryan Bolger,

@RyanBolger Sì, proprio come hai detto. Il mio cliente ha richiesto un certificato dog.example.come mi ha inviato il certificato e la chiave privata. Ho messo quelli dentro Server Be ho configurato Nginx per usarli. E ora funziona tutto bene. Grazie!
user2875289

Solo una nota su un punto di tecnicismo; dato che ora ci sono dischi "ALIAS", non direi che anche i CNAME siano alias;]
Garet Claborn,

9

Volevo capire se la mia azienda tenant ha un certificato SSL con caratteri jolly, funzionerà con questa configurazione o se è necessario acquistare un nuovo certificato SSL docs.tenantcompany.com?

Risposta breve: No. Se la tua società tenant ha un carattere jolly nel nome *.tenantcompany.com, è sufficiente installarlo sul tuo server per coprire gli accessi con quel nome. Se vuoi farlo o no è un'altra storia.

Un certificato nel nome docs.<tenant>.mycompany.com(ad esempio un certificato diretto o un carattere jolly *.<tenant>.mycompany.com) è inutile se l'accesso viene sempre effettuato tramite il docs.tenantcompany.comnome.


Risposta più lunga

Supponi di navigare https://docs.tenantcompany.comin un browser ragionevole. Il browser esegue TLS sul protocollo HTTP. Si preoccupa in particolare di due cose; quello:

  • il sottosistema DNS del browser e del sistema operativo restituisce l'indirizzo IP di un host adatto, che esegue un server Web su una porta adatta altrove sulla rete locale o su Internet. Per il traffico HTTPS (protetto), la porta predefinita è 443se non diversamente sostituito nell'URL.

  • Quando l' handshake TLS avviene tra il browser e il server remoto, il server presenta un certificato attendibile che gli consente di fornire un servizio TLS all'indirizzo richiesto ( docs.tenantcompany.com).

DNS

Il browser vede DNS come una scatola nera. Fa una chiamata a una libreria DNS adatta per chiedere una mappatura da un nome di dominio completo (FQDN) a un indirizzo IP adatto (v4 o v6). Non importa come ottiene quell'indirizzo IP. Se ci sono 20 CNAMEalias nel DNS tra il record originale e un Ao AAAArecord, il risolutore DNS li seguirà fino a ottenere un indirizzo IP.

TLS

Quando il browser esegue l' handshake TLS , ha bisogno di verificare che il server si sta comunicando con è autorizzato a fornire un servizio sito web sicuro sul nome di dominio completo richiesto: docs.tenantcompany.com.

Ricorda: il browser non se ne preoccupa docs.<tenant>.mycompany.com: il resolver DNS ha sottratto tutta la conoscenza della direzione indiretta tramite un CNAMErecord.

Il nostro metodo per autorizzare il server a servire sessioni sicure docs.tenantcompany.comè tramite un certificato SSL che è firmato da un'autorità per la quale è stata stabilita la fiducia precedente nell'archivio certificati radice del browser. Questa non è sempre la forma più forte di autenticazione da server a client - molti possono andare storti nel modello CA centralizzato - ma è la migliore che abbiamo al momento.

Ci sono altre due avvertenze qui:

Condivisione chiave

Molti fornitori commerciali di certificati SSL firmeranno solo una singola richiesta di firma, che vincola efficacemente il certificato jolly a una singola chiave privata. La società locataria potrebbe non essere a proprio agio nel condividerla al di fuori della propria organizzazione, in quanto chiunque sia in possesso della chiave privata può ovviamente compromettere la comunicazione con gli altri sistemi protetti dell'azienda locataria.

Alcuni fornitori firmeranno più richieste di firma del certificato con lo stesso certificato, il che consente di installare un singolo certificato jolly su più server e sistemi senza condividere la chiave privata tra di loro.

Il mascheramento

Se la società locataria fornisce una copia del proprio certificato jolly (condividendo la chiave privata o firmando il proprio CSR), è possibile mascherarsi come <anydomain>.tenantcompany.com, abbattendo un'importante protezione che garantisce l'integrità dei server identificati nello tenantcompany.comspazio dei nomi DNS. Questa potrebbe essere una cattiva posizione per te e per la società inquilina, da un punto di vista legale / di responsabilità.


Grazie mille per la risposta dettagliata. È molto utile e mi ha aiutato a considerare gli aspetti etici e legali di ciò che sto cercando di fare.
codematix,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.