Eu devo ter um certificado por servidor?

Question

Estou criando um serviço no Azure. Agora tenho 2 servidores

• DC-1
• Trabalhador-1

O Worker-1 faz serviços http, ftp e um par de .exe que estão funcionando 24 horas por dia. Tanto o DC quanto o Worker fazem parte de um domínio .com que eu configurei.

Eu precisava proteger alguns serviços HTTPS no Worker-1, por isso recebi um certificado SSL de "domínio verificado". Agora preciso proteger o serviço FTP que está em execução também ...

1) Posso usar o mesmo certificado ou preciso obter outro "domínio verificado" para o ftp.foo.com (ftp)?

2) Obter um certificado SSL curinga resolve o problema acima, onde posso proteger os dois (e mais) ftps: //asd1.foo.com e o link ?

Por favor, olhe 1) como dois certificados simples são mais baratos do que um curinga, então, por enquanto, pode ser a melhor solução econômica.

3) E se eu movesse o serviço FTPS para outro servidor? Se eu criar o Worker-2 e configurar o serviço FTPS nisso. Ainda posso utilizar o mesmo certificado? Acho que pelo menos preciso de um curinga aqui, pois ainda tenho os https em execução no Worker-1.

Ou eu, neste caso, preciso de um certificado "Organização Verificada"? Eu entendo que existem três tipos, certificados DV, OV e EV. Eu poderia em 3) simplesmente adicionar os certificados para o Active Directory e tudo é executado magicamente? :) Pensamento de desejo, não sei como os certificados funcionam em servidores cruzados em um domínio.

    

Answer 1

Tecnicamente, não há muita diferença entre DV, OV e EV. Eles são todos apenas certificados SSL atribuídos a um determinado nome de assunto ou grupo de nomes.

Não há nada errado em usar um certificado em vários servidores, desde que o certificado cubra os nomes dos assuntos que você está usando. Se o seu certificado existente não listar ftp.domain.com, você não poderá usá-lo para esse nome de host.

A opção mais simples se você já possui um certificado para domain.com é simplesmente obter outro para ftp.domain.com.

Você também pode obter um certificado "SAN" que abrange vários nomes. O certificado tem uma lista de nomes alternativos, ftp.domain.com, mail.domain.com, etc. O provedor que eu uso vende certificados que cobrem até 5 nomes para não muito mais do que um único. (O nome SAN vem do campo que contém esses nomes dentro do certificado - "Subject Alternative Names". Você pode visualizá-los nas propriedades do certificado)

Um certificado curinga também deve funcionar - embora tenha certeza de que ele realmente cubra "domain.com" e não apenas "something.domain.com". Isso provavelmente é mais caro do que um certificado SAN, mas dá a você liberdade para configurar o someservice.domain.com no futuro e usar o certificado existente.