Ligação SSL sem nome de host e armazenamento de certificado centralizado?

Question

Temos um aplicativo da Web que serve um grande número de sites de um único site do IIS. O site do IIS simplesmente tem uma ligação catch-all na porta 80. Até agora, para as ligações SSL, adicionamos um novo IP à máquina para cada domínio que precisa de SSL e adicionamos uma ligação SSL a esse endereço IP específico.

Agora estamos investigando o armazenamento de certificados centralizado. Achamos que agora poderíamos ter uma ligação SSL pega-tudo que usaria apenas o nome do host fornecido e procuraria o certificado no CCS. Mas isso não parece ser o caso. Você pode adicionar uma ligação SSL pega-tudo com um certificado específico instalado no IIS local ou pode adicionar ligações SSL individuais usando o CCS, mas é necessário especificar um nome de host.

Se eu estiver correto, então isso é uma pegadinha para nós; Ainda seremos uma ligação para cada certificado em uso, mesmo que o próprio certificado esteja no CCS. Estou correto?

EDITAR: Este é um aplicativo altamente segmentado. Há cerca de cem clientes sendo atendidos, com milhares de nomes de host únicos, todos em execução no mesmo aplicativo da Web; o aplicativo usa um banco de dados para determinar qual conteúdo será exibido para cada nome de host.

Ter uma ligação separada para cada nome de host usado para acessar o aplicativo é um total não inicial. E manter os certificados SSL carregados na instância local do IIS também não é um bom começo; temos lidado com isso até agora e está ficando pesado.

Na porta 80, posso ter uma ligação de pega-tudo; qualquer nome de host usado para conectar-se será direcionado para o aplicativo da Web.

Na porta 443, aparentemente não posso fazer isso a menos que o certificado seja carregado na instância do IIS em vez do CCS. E apenas um certificado curinga por endereço IP pode ser usado dessa maneira. Eu não posso usar o nome de host passado por SNI para procurar o certificado apropriado; o nome do host passado deve corresponder a uma ligação primeiro.

A situação ideal seria se eu pudesse ter uma ligação catch-all na porta 443 com ele procurando automaticamente o certificado apropriado com base no nome de host passado. Não parece que o IIS quer me deixar fazer isso.

Isso é extremamente deprimente. Parece que vamos ter que abrir mão do IIS para isso e descarregar todo o SSL para algo baseado no Apache, o que parece muito mais flexível.

    

Answer 1

Após investigar apache e nginx , estabeleci haproxy-1.5 . A versão 1.5 integrou o suporte https exatamente do tipo que eu preciso. Depois que o haproxy.cfg adequado tiver sido gravado para especificar os nós do balanceador de carga, tudo o que eu preciso fazer depois disso é transformar meus arquivos certificados PFX exportados em arquivos PEM usando openssl e despejá-los em uma pasta. Minha vinculação completa funcionará bem.

Claro que ainda tenho problemas regulares com proxy reverso ... mas nada diferente do que eu já tinha resolvido com meu balanceador ARR.

Aqui está uma parte do meu haproxy.cfg (limpo, claro)

frontend http-in
    bind *:80
    bind *:443 ssl crt /media/windowsshare/myWindowsServer/ssl/pem/
    default_backend myCluster

backend myCluster
    server member1 10.4.0.184:80 maxconn 64
    server member2 10.4.0.185:80 maxconn 64

    

Answer 2

No IIS 10, você pode ter:

Name              Bindings
----              --------
Default Web Site  https *:443:*.bar.com sslFlags=3
                  https *:443:*.bar.net sslFlags=3
                  https *:443:*.foo.edu sslFlags=3         

e use o CCS para todas as ligações, mas você não pode fazer:

https *:443:*.*.com sslFlags=3  

ou

https *:443:*.com sslFlags=3

Portanto, se todos os seus domínios forem domínios de nível superior diferentes, isso não é muito útil, mas se você tiver algo como username.domain.com e o domínio for o mesmo para todos os nomes de host, será muito útil.

    

Answer 3

Você está falando de dois conceitos diferentes aqui:

1. SNI, a capacidade de usar TLS (o SSL está inativo) com base em um nome de host, para que você não precise de um endereço IP separado para cada site TLS.

2. O armazenamento de certificados central, que apenas altera a maneira como o IIS armazena os certificados e facilita a sua implantação. Para usar o CCS, é necessário definir o nome do host na ligação, porque ele é usado para localizar o arquivo PFX de certificado correto.

Mas você pode misturar e combinar, você ainda pode usar certificados armazenados no antigo repositório de certificados para algumas ligações e o CSS para outros.

Mas você não pode ter uma única ligação para tudo e dizer para usar o CCS.

Dica: gerencie suas ligações e atribuições de certificados em um script, nunca clique no Gerenciador do IIS.