Sto creando un server WebSocket su cui vivrà ws.mysite.example. Voglio che il server socket Web sia crittografato SSL e domain.examplesia crittografato SSL. Devo acquistare un nuovo certificato per ogni sottodominio che creo? Ho bisogno di un indirizzo IP dedicato per ogni sottodominio che creo? Probabilmente avrò più di un sottodominio.
Sto usando NGINX e Gunicorn in esecuzione su Ubuntu.
Risposte:
Ti risponderò in due passaggi ...
Hai bisogno di un certificato SSL per ciascun sottodominio?
Sì e No, dipende. Il tuo certificato SSL standard sarà per singolo dominio, diciamo www.domain.example. Esistono diversi tipi di certificati oltre al certificato singolo dominio standard: caratteri jolly e certificati multi dominio.
Un CERT wild card sarà rilasciato per una cosa del genere *.domain.examplee clienti tratterà questo come valida per qualsiasi dominio che termina con domain.example, ad esempio www.domain.exampleo ws.domain.example.
Un certificato multi dominio è valido per un elenco predefinito di nomi di dominio. Lo fa usando il campo Nome alternativo soggetto del certificato. Ad esempio, è possibile indicare a una CA che si desidera un certificato multi dominio per domain.examplee ws.mysite.example. Ciò consentirebbe di essere utilizzato per entrambi i nomi di dominio.
Se nessuna di queste opzioni funziona per te, allora dovresti avere due certificati SSL diversi.
Ho bisogno di un IP dedicato per ciascun sottodominio?
Ancora una volta, questo è un sì e no ... tutto dipende dal tuo web / application server. Sono un ragazzo di Windows, quindi risponderò con esempi IIS.
Se usi IIS7 o versioni precedenti, sei costretto a associare certificati SSL a un IP e non puoi avere più certificati assegnati a un singolo IP. Ciò comporta la necessità di disporre di un IP diverso per ciascun sottodominio se si utilizza un certificato SSL dedicato per ciascun sottodominio. Se si utilizza un certificato multi dominio o un certificato jolly, è possibile cavarsela con il singolo IP in quanto si ha solo un certificato SSL per cominciare.
Se si esegue IIS8 o versione successiva, lo stesso vale. Tuttavia, IIS8 + include il supporto per qualcosa chiamato Server Name Indication (SNI). SNI ti consente di associare un certificato SSL a un nome host, non a un IP. Pertanto, il nome host (Nome server) utilizzato per effettuare la richiesta viene utilizzato per indicare quale certificato SSL utilizzare IIS per la richiesta.
Se si utilizza un singolo IP, è possibile configurare i siti Web per rispondere alle richieste di nomi host specifici.
So che Apache e Tomcat hanno anche il supporto per SNI, ma non li conosco abbastanza per sapere quali versioni lo supportano.
Linea di fondo
A seconda dell'applicazione / del server Web e del tipo di certificati SSL che è possibile ottenere determineranno le opzioni.
abc.def.domain.com, è così?
È possibile ottenere un certificato per ciascun sottodominio, un certificato con più sottodomini o un certificato con caratteri jolly (per *.yoursite.example).
Tuttavia, in genere costano un po 'di più rispetto ai certificati regolari e, poiché condividi un singolo certificato, in genere non sono l'opzione migliore dal punto di vista della sicurezza, a meno che non si ospiti un anything.mydomain.exampletipo di applicazione in cui sono l'unica scelta praticabile.
Inoltre, non è necessario disporre di più indirizzi IP se si dispone di un server Web abilitato SNI . Detto questo, SNI è supportato solo nei browser moderni (IE6 e versioni successive non funzionano con esso). Le versioni recenti di Nginx e Apache supportano SNI in modo trasparente (basta aggiungere host virtuali abilitati SSL).
O avrai bisogno di un certificato separato per ogni sottodominio, oppure puoi acquistare un carattere jolly cert ( *.domain.example) - più costoso, ma ha senso se stai ospitando molti sottodomini.
Per quanto riguarda gli IP, dipende da come si configura il server. È possibile utilizzare le regole del nome host per servire più siti dallo stesso IP o utilizzare IP univoci per ognuno. Ci sono pro e contro in entrambi i metodi.