Eu escrevi um aplicativo ASP.NET MVC que permite ao usuário especificar seu próprio domínio personalizado. Tenho o IIS configurado para enviar todas as solicitações ao site padrão, portanto não preciso usar cabeçalhos de host. Tudo funciona perfeitamente. O único problema é SSL.
Eu sei que esta pergunta foi feita várias vezes em muitos fóruns, mas as respostas geralmente entram em conflito ou falam em termos absolutos como (isso não pode ser feito). Isso não é realmente uma opção para mim. O que procuro aqui são algumas opções; Estou aberto ao não convencional :).
Tenho visto algumas respostas construtivas que sugerem o uso do servidor ISA como proxy SSL. Alguém sabe mais sobre isso? Ou alguém configurou isso e teve sucesso?
Basicamente, quero fornecer aos meus usuários uma maneira de solicitar um CSR do aplicativo, comprar e baixar um certificado SSL, voltar ao meu aplicativo e fazer upload do certificado emitido por uma empresa de certificação autorizada.
Gostaria de fazer isso sem precisar fornecer endereços IP separados para clientes que desejam usar um domínio personalizado e SSL em seus sites. Isso ocorre simplesmente porque meu aplicativo está hospedado na nuvem da Amazon e eles não estão interessados em me fornecer um grande bloco de endereços IP.
Meu aplicativo pode ser hospedado no IIS6 ou IIS7.
SOLUÇÃO: Obrigado por toda sua ajuda com esse pessoal. Certamente não entendi esse problema tão bem como agora. Acho que minha solução por enquanto será gerar um certificado curinga e forçar meus clientes a usar clientname.someshareddomain.com se quiserem uma conexão segura. Para clientes que simplesmente não concordam com isso, provavelmente fornecerei outro endereço IP elástico por meio de uma chamada de API para Amazon Web Services, criarei um novo site no IIS e apontarei para a pasta raiz do meu aplicativo e, em seguida, gerarei programaticamente um CSR a partir disso novo site. Só vou ter que fazer algum tipo de acordo com a Amazon para me dar um bloco decente de endereços IP.
Responder1
Lamento muito que você não goste da resposta "você não pode fazer isso", mas não pode fazer o que deseja. A tecnologia simplesmente não permite que isso funcione da maneira que você deseja.
Aqui está o porquê.
O protocolo HTTP permite que mais de um servidor compartilhe um endereço IP. Isso é feito por meio do cabeçalho HTTP/1.1 Host:
Host: servername.example.com
O handshake SSL aconteceanteso handshake HTTP acontece. Isso significa que o servidor não tem ideia de qual certificado apresentar ao cliente com base no servidor que o cliente deseja.
Portanto, tente o quanto quiser, mas vários certificados não podem ser usados em um único endereço IP. Não importa o quanto você tente, nem o quanto isso não é uma opção para você.
Responder2
Como disse Michael, se algo é impossível, bater o pé e fazer beicinho não muda as coisas.
Colocar certificados SSL separados em endereços IP separados não é um problema, tecnologicamente falando; é apenas uma questão de provisionamento (que é uma simples questão de programação) e de ter um provedor de rede que entenda as necessidades de empresas de grande porte e esteja disposto a pré-alocar um bloco de endereços de tamanho decente para domínios SSL.
No entanto, existe outra opção, conhecida como "Indicação do nome do servidor", por meio do qual o navegador pode informar ao servidor com qual vhost ele deseja conversar no momento da negociação SSL, para que o servidor possa apresentar o certificado correto. Infelizmente, o suporte para isso não é universal; de acordo com a página da Wikipedia acima, nem o IIS 6 nem o 7 pode lidar com isso no lado do servidor, e você precisa estar executando o Vista para usá-lo com o IE no lado do cliente (Firefox, Opera e Chrome já o suportam há algum tempo).
Portanto, se você deseja mudar para um servidor Web decente e alienar qualquer parte da sua base de usuários que ainda usa navegadores desatualizados em sistemas operacionais Microsoft mais antigos, você pode usá-lo. Ninguém parece querer incomodar a tia Tillie rodando o IE 5.5 no Windows 98...
Responder3
Se a questão é fornecer sessões seguras (e não sobre cada cliente possuir seu próprio certificado), por que não eliminar a carga e a complexidade de cena usando um certificado SSL curinga?