Início > Não categorizado > Web Publishings com vários certificados digitais

Web Publishings com vários certificados digitais

Saudações,

A algum tempo atrás, falamos aqui de um caso que atendi em que o cliente queria publicar uma aplicação no ISA Server, porém, havia uma dificuldade na criação do listener. Ele iria usar um outro certificado digital e na hora de criar o listener, ele recebia um erro referente a porta 443, que já estava em uso por outras aplicações que também tinham um outro certificado digital definido no listener.

A solução deste caso, vc pode ver clicando aqui para ver como era o ambiente e como resolvemos este caso.

Agora, como ficará o acesso a este ISA Server, caso outras aplicações em SSL precisem ser publicadas? É óbvio que existem milhões de cenários, onde isto não seria um problema. Algumas empresas, além do firewall de borda, utilizam appliances (Net Defender por exemplo) que permitem o Web Server ser publicado diretamente na internet, sem o perigo de invasão, o que não é o caso deste ambiente.

Como esse equipamento não existe no cliente, todos os acessos a aplicações WEB no ambiente extranet, tanto da própria empresa, quanto por parceiros externos, são feitas a partir de publicação no ISA Server, que redireciona estas requisições para o web server correto.

Caso vc não tenha muita experiência com Web Publishing no ISA/TMG, clique aqui e veja um tutorial completo sobre o tema.

O mesmo ISA Server do post anterior está recebendo uma nova aplicação e os gestores decidiram que a URL tinha que ser outra. Desta forma, um novo certificado digital teria que ser emitido. Neste caso um para cada ambiente (produção e qualidade). Desta forma, mais 2 IP’s foram adicionados a placa interna, um para cada ambiente desta nova aplicação.

Após alguns testes, vimos que o ISA está se comportando bem e não está havendo problemas de performance, uma vez que, a rede interna estará endereçando aplicações em HTTP para um listener, HTTPS para outro listener e também para outros com certificados específicos.

Após a descrição acima, queria deixar algumas recomendações, para que se possa evitar casos como este:

1. Toda implementação de ISA/TMG tem que ser planejada e pensada antes de qualquer coisa. Planeje tudo o que será implementado antes da instalação. Caso contrário você se perde no meio do caminho.

2. Mantenha um padrão de URL’s. Não fique inventando endereços para aplicações que atendem a mesma corporação. Vc pode (usando pubslishing do ISA) ter o mesmo endereço em vários Web Servers, obviamente, com paths diferentes. Desta forma, usa-se somente um certificado digital você não precisa ficar criando um monte de listeners.

3. Caso não seja possível priorizar o que foi indicado no item 2, sugiro que sua corporação pense no uso do certificado tipo SAN (Subject Alternative Name). Neste caso você poderá publicar aplicações com os mais variados nomes no host, respeitando o domínio, pois, ele vem com issue para *.empresa.com.br. Estes certificados são mais caros, porém, duram até 3 anos e se juntar o que se gasta na compra de vários certificados, ele acaba saindo muito mais em conta.

4. Em um último caso, coloque seu web server direto na internet e o proteja com o firewall e appliances próprios para barrar invasões como Net Defender.

Pense nestas sugestões na hora de planejar uma estrutura de publicação WEB, você não vai poder ficar enchendo sua placa de IP’s a vida toda.

Espero que este artigo seja útil!

Abraços

Uilson

Categorias:Não categorizado
  1. 3 de novembro de 2010 às 18:26

    Olá Uilson,

    Muito boa a sumarização para este tipo de cenário, só uma pequena correção no ítem abaixo:

    “3. Caso não seja possível priorizar o que foi indicado no item 2, sugiro que sua corporação pense no uso do certificado tipo SAN (Subject Alternative Name). Neste caso você poderá publicar aplicações com os mais variados nomes no host, respeitando o domínio, pois, ele vem com issue para *.empresa.com.br. Estes certificados são mais caros, porém, duram até 3 anos e se juntar o que se gasta na compra de vários certificados, ele acaba saindo muito mais em conta.”

    Certificado do tipo SAN é quando você tem vários nomes no mesmo certificado, como por exemplo:
    owa.contoso.com
    mail.contoso.com
    autodiscover.contoso.com

    Note que no SAN você tem que ter os nomes explicítos no certificado, o exemplo que você deu *.empresa.com.br, chama-se wildcard certificate. Há diferença de preço entre um SAN e um wildcard.

    Grande abraço,

    Yuri Diogenes

    • 3 de novembro de 2010 às 21:10

      Opa…vc tem razão…troquei as bolas! o WildCard foi o que sugeri pra empresa…foi mal!

  1. No trackbacks yet.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: