Estou criando um servidor websocket que permanecerá ativo ws.mysite.example. Quero que o servidor de soquete da Web seja criptografado por SSL e também por domain.exampleSSL. Preciso comprar um novo certificado para cada subdomínio que eu criar? Preciso de um endereço IP dedicado para cada subdomínio que eu criar? Provavelmente terei mais de um subdomínio.
Estou usando o NGINX e o Gunicorn em execução no Ubuntu.
Respostas:
Vou responder isso em duas etapas ...
Você precisa de um certificado SSL para cada subdomínio?
Sim e não, depende. Seu certificado SSL padrão será para um único domínio, por exemplo www.domain.example. Existem diferentes tipos de certificados que você pode além do certificado padrão de domínio único: certificados curinga e de vários domínios.
Um certificado curinga será emitido para algo como *.domain.examplee os clientes tratarão isso como válido para qualquer domínio que termine com domain.example, como www.domain.exampleou ws.domain.example.
Um certificado de vários domínios é válido para uma lista predefinida de nomes de domínio. Isso é feito usando o campo Nome alternativo do assunto do certificado. Por exemplo, você pode dizer a uma CA que deseja um certificado de vários domínios para domain.examplee ws.mysite.example. Isso permitiria que fosse usado para os dois nomes de domínio.
Se nenhuma dessas opções funcionar para você, você precisará ter dois certificados SSL diferentes.
Preciso de um IP dedicado para cada subdomínio?
Novamente, este é um sim e não ... tudo depende do seu servidor de aplicativos / web. Eu sou um cara do Windows, então vou responder com exemplos do IIS.
Se você estiver executando o IIS7 ou mais antigo, será obrigado a vincular certificados SSL a um IP e não poderá ter vários certificados atribuídos a um único IP. Isso faz com que você precise ter um IP diferente para cada subdomínio se estiver usando um certificado SSL dedicado para cada subdomínio. Se você estiver usando um certificado de vários domínios ou um curinga, poderá obter um único IP, pois você só tem um certificado SSL para começar.
Se você estiver executando o IIS8 ou posterior, o mesmo se aplica. No entanto, o IIS8 + inclui suporte para algo chamado Server Name Indication (SNI). O SNI permite vincular um certificado SSL a um nome de host, não a um IP. Portanto, o nome do host (nome do servidor) usado para fazer a solicitação é usado para indicar qual certificado SSL o IIS deve usar para a solicitação.
Se você usar um único IP, poderá configurar sites para responder a solicitações de nomes de host específicos.
Eu sei que o Apache e o Tomcat também têm suporte para o SNI, mas não os conheço o suficiente para saber quais versões o suportam.
Bottom Line
Dependendo do seu aplicativo / servidor da Web e que tipo de certificado SSL você pode obter, ditará suas opções.
abc.def.domain.com, é esse também o caso?
Você pode obter um certificado para cada subdomínio, um certificado de subdomínio múltiplo ou um certificado curinga (para *.yoursite.example).
No entanto, eles geralmente custam um pouco mais do que os certificados regulares e, como você compartilha um único certificado, eles geralmente não são a melhor opção do ponto de vista da segurança, a menos que você hospede um anything.mydomain.exampletipo de aplicativo em que eles são a única opção viável.
Você também não precisa de vários endereços IP se tiver um servidor da Web compatível com SNI . Dito isto, o SNI é suportado apenas em navegadores modernos (o IE6 e abaixo não funcionam com ele). Versões recentes do Nginx e Apache suportam SNI de forma transparente (basta adicionar hosts virtuais habilitados para SSL).
Você precisará de um certificado separado para cada subdomínio ou poderá adquirir um certificado curinga ( *.domain.example) - mais caro, mas faz sentido se estiver hospedando muitos subdomínios.
Em relação aos IPs, isso depende de como você configura seu servidor. Você pode usar regras de nome de host para atender a vários sites do mesmo IP ou usar IPs exclusivos para cada um. Existem prós e contras nos dois métodos.