Estou criando um servidor websocket que viverá no ws.mysite.example
. Eu quero que o servidor de soquete da web seja criptografado por SSL e também criptografado por domain.example
SSL. Preciso comprar um novo certificado para cada subdomínio que crio? Preciso de um endereço IP dedicado para cada subdomínio que crio? Provavelmente terei mais de um subdomínio.
Estou usando NGINX e Gunicorn rodando no Ubuntu.
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 domínio único, digamos
www.domain.example
. Existem diferentes tipos de certificados que você pode além do certificado de domínio único padrão: certificados curinga e de vários domínios.Um certificado curinga será emitido para algo como
*.domain.example
e os clientes tratarão isso como válido para qualquer domínio que termine comdomain.example
, comowww.domain.example
ouws.domain.example
.Um certificado de vários domínios é válido para uma lista predefinida de nomes de domínio. Ele faz isso usando o campo Subject Alternative Name do certificado. Por exemplo, você pode informar a uma CA que deseja um certificado de vários domínios para
domain.example
ews.mysite.example
. Isso permitiria que ele fosse usado para ambos os 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, isso é um sim e um não... tudo depende do seu servidor web/aplicativo. Eu sou um cara do Windows, então vou responder com exemplos do IIS.
Se você estiver executando o IIS7 ou mais antigo, será forçado 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 certificado curinga, poderá se safar com o IP único, pois 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 que você vincule 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 SNI, mas não os conheço o suficiente para saber quais versões o suportam.
Resultado final
Dependendo do seu aplicativo/servidor da Web e do tipo de certificados SSL que você pode obter, determinará suas opções.
Você pode obter um certificado para cada subdomínio, um certificado de vários subdomínios 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.example
tipo de aplicativo em que eles sejam a única opção viável.Você também não precisa de vários endereços IP se tiver um servidor Web compatível com SNI . Dito isto, o SNI é suportado apenas em navegadores modernos (IE6 e abaixo não funcionarão com ele). Versões recentes do Nginx e Apache suportam SNI de forma transparente (basta adicionar hosts virtuais habilitados para SSL).
Eu recomendo " getssl " para criar Certificação SSL para subdomínio hospedado em outro servidor.
Você pode usar " getssl " para criar um certificado SSL para o subdomínio que usa letsencrypt.org
Você precisará de um certificado separado para cada subdomínio ou poderá comprar um certificado curinga (
*.domain.example
) - mais caro, mas faz sentido se você estiver hospedando muitos subdomínios.Em relação aos IPs, 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. Há prós e contras em ambos os métodos.