Certificado SSL curinga em vários ELBs no VPC

Question

Sou muito novo na instalação de certificados e na própria AWS. Agora, na minha infraestrutura atual, tenho 3 ELBs que estão em um VPC.

Eu comprei um certificado ssl curinga da COMODO através do Big Rock.

O que eu quero é que toda a comunicação entre meus ELBs e o mundo externo seja via HTTPS.

1. Como posso conseguir isso?
2. Posso instalar o único certificado de curinga que possuo em todos os três ELBs?
3. Existe uma maneira melhor de fazer isso?
4. Além disso, como é um certificado de wild card que eu tenho, eu não seria capaz de usá-lo para api.example.com, mas não para example.com em si (pelo meu entendimento). No entanto, o que é visível para o externo mundo é example.com por enquanto (e não é realmente api.example.com) Preciso comprar outro certificado para o cenário acima?
5. Que tipo de certificado (eu li sobre Certs SSL do UCC aqui ) devo ir com, dado que eu também tenho example.in como um domínio, bem como onde o mesmo site está hospedado.

Por favor, perdoe minha ignorância sobre o assunto.

    

Answer 1

What I want is that all the communication between my ELBs and the external world should be over HTTPS. How can I achieve this ?

Desativar completamente o HTTP simples geralmente não está disponível, mas pode configurar seus servidores da web para redirecionar (permanentemente) qualquer solicitação não criptografada de http://... para https://...

Can I install the one wild card certificate that I have on all the three ELBs?

Não há razão técnica para você não conseguir.

Also since it is a wild card certificate that I have, I would not be able to use it for api.example.com but not for example.com itself (as per my understanding).
However, what is visible to the external world is example.com for now (and not really api.example.com) So do I need to purchase another certificate for the above scenario ?

Sim, um curinga para *.example.com é válido apenas para <valid_hostnames>.example.com e nem para% /example.com nem *.*.example.com simples / nus funcionará. Consulte este Q & A para obter detalhes.

Tecnicamente também é possível incluir o domínio simples com o certificado curinga por meio de uma extensão de Nome alternativo para o assunto, tornando o certificado válido para *.example.com e example.com , mas que os revendedores SSL fazem isso automaticamente Eu não sei. Então você pode não precisar de outro certificado (de substituição).

Você pode verificar com openssl x509 -in certificate.crt -text -noout , o que gerará algo semelhante a quando SubjectAltNames estão presentes:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
           ....
        Subject: ..., CN=*.example.com
           ...
        X509v3 extensions:
           ...
           X509v3 Subject Alternative Name:
                DNS:*.example.com, DNS:example.com

Se esse não for o caso, você pode precisar de outro certificado para poder usar o domínio simples, além do curinga atual. Indicação do nome do servidor (SNI) é o que seria necessário para usar dois certificados SSL diferentes e fazê-los funcionar corretamente em um único Instância do ELB.

Infelizmente, conforme declarado na documentação do Elastic Load Balancing em relação ao HTTPS:

Elastic Load Balancing does not support Server Name Indication (SNI) on your load balancer.

Portanto, dois certificados em um ELB não são permitidos.

Which type of certificate (I read about UCC SSL Certs here)should I go with, given that I also have example.in as a domain as well where the same site is hosted.

A documentação do produto ELB apresenta duas estratégias:

• Compre um único certificado de vários domínios com SAN (Subject Alternative Name) para cada domínio adicional (às vezes chamado de Certificado de Comunicações Unificadas (UCC) em vez de Certificado SAN) e use-o no ELB.

• Use ouvintes TCP na porta 443 para as conexões front-end e back-end. O balanceador de carga transmite a solicitação e você manipula a terminação HTTPS da instância do EC2, com um servidor da Web que suporta SNI.

Answer 2

Se o certificado Wildcard SSL for emitido para * .example.com, você poderá proteger example.com, api.example.com e qualquer outro subdomínio com um único certificado SSL curinga. Comodo Wildcard SSL oferece licenças de servidor ilimitadas e você deve instalar o certificado em todos os seus 3 ELBs para configurar um ambiente seguro em seus subdomínios.

Se você quiser proteger diferentes nomes de domínio que se referem a diferentes TLDs como example.com, example.in e example.anytld, então você deve usar o certificado SSL do UCC. Você pode adicionar ou editar nomes alternativos de assunto (SAN) a qualquer momento durante a vida útil do certificado.

Se a sua exigência é proteger vários sites e todos os seus subdomínios, você pode usar o Comodo Multi Domain Wildcard SSL .