Início > Certificado Digital, IIS, Scripts, Segurança > Tips and Tricks–certificados digitais wildcard ou SAN no IIS Windows Server 2003, Windows Server 2008 e Windows Server 2012 R2

Tips and Tricks–certificados digitais wildcard ou SAN no IIS Windows Server 2003, Windows Server 2008 e Windows Server 2012 R2

Saudações,

Depois de alguns meses carregados de palestras que entreguei e a série de posts sobre migração do TMG para plataformas distintas, comecei um trabalho de migração de aplicações WEB. A principio o processo pedia somente migração do IIS 6.0 para IIS 7.5 e 8.5.

Em alguns casos foi preciso manter a aplicação em ambiente legado (2003) por questões de compatibilidade e falta de tempo da equipe de DEV para migração.

Além disso, para as aplicações em ambiente legado e também as que foram migradas, era necessário uso de certificado digital wildcard. Como eram aplicações que não seriam acessadas externamente, pudemos usar o template Web Server da própria entidade certificadora interna (AD CS).

Nesse ponto encontramos alguns pontos que devem ser observados em aplicações WEB legadas em IIS 6.0. O padrão da empresa era manter diversos sites no IIS, cada um com sua aplicação e para cada uma delas seria necessário certificado. Pensei em gerar um wildcard mas, um certificado SAN contendo todos os comon names dos hosts já havia sido criado.

Em tese no IIS 6.0, você não pode ter diversos sites apontando para um único certicado, nem tampouco usar a porta 443 para mais de um certificado no mesmo IP. Tinha dua opções:

A) Adiconar IP´s associando a cada uma das aplicações

B) Usar uma linha de comando do ADSUTIL para fazer a criação de secure binds que possibilitarão o uso do mesmo certificado para as diversas aplicações associadas a um único IP

Bom, devido as condições e a urgência, optamos pela opção B. Para tal, você precisa executar o seguinte comando do ADSUTIL (lembrando que o ADSUTIL fica na pasta inetpub\adminscripts):

cscript.exe adsutil.vbs set /w3svc/<site identifier> /SecureBindings “:443<host header>”

No comando acima:

<site identifier> – identificação do site no IIS

<host header> – endereço ao qual o site irá responder – ex: app.uilson.net ou www.uilson.net

Antes de colocar o exemplo prático do comando para IIS 6.0, veja como verificar o ID do site nos IIS´s 6.0 e também no 8.5 do 2012 R2:

IIS 6.0 – Windows Server 2003

image

IIS 7.5 e 8.5 – Windows Server 2008 R2 e Windows Server 2012 R2:

image

Agora que você já sabe, ou se lembrou como identificar o ID# do site, vamos ao comando de forma prática. Apenas relembrando que o procedimento abaixo se aplica ao IIS 6.0:

cscript.exe adsutil.vbs set /w3svc/856101042/SecureBindings ":443:www.uilson.net"
cscript.exe adsutil.vbs set /w3svc/620385459/SecureBindings ":443:aplication.uilson.net"
cscript.exe adsutil.vbs set /w3svc/1953820003/SecureBindings ":443:webapp.uilson.net"

Importante frisar que:

. Os sites devem estar parados para que os comandos sejam executados

. Se houver qualquer alteração nas configurações de SSL do site, o comando acima deverá ser aplicado novamente

Dessa forma o problema foi resolvido e temos mais um tempo até a equipe de dev migrar a aplicação.

Para quem usa IIS no Windows Server 2008 e 2012, as coisas são um pouco menos trabalhosas. Uma vez que um site usa o certificado SAN (com mais deu common name criado ou wildcard), assim que vc assinala o certificado em um site, você receberá uma mensagem ao assinalar o mesmo certificado para o próximo, dizendo que o certicado já está sendo usado e que, todos os demais sites, se forem habilitados a porta 443, irão usar o mesmo que foi assinalado para os anteriores. Dessa forma ficou mais rápido e simples de resolver.

O redirect para https poderá ser feito por sua infra de proxy reverso, entretanto você também poderá faze-lo pelo próprio IIS de forma simples:

IIS 6.0 – Windows Server 2003 – Propriedades do site / custom errors / edit no erro 403.1 e inserir a URL https conforme abaixo:

image

IIS 7.5 e 8.5 – Windows Server 2008 e Windows Server 2012 R2 –

image

Estas foram alguns tips and tricks que estou compartilhando com vcs acerca de configuração de certificados digitais no IIS. Recomendo que, por questões de segurança, procure migrar suas aplicações legadas para o IIS 8.5, pois além de toda uma linha de features que você tem a disposição na versão atual, você ainda pode trabalhar com certificados de encriptação maior SHA2 em 256 bits.

Além disso, o IIS 8.5 tem suporte a SNI (Server Name indication), uma extensão TLS a qual possibilita saber o host e o domínio da página onde a requisição está sendo feita. Está disponível a partir do IIS 8.0 do Windows Server 2012 e é suportado em browser a partir do IE 7. Para saber mais detalhes, clique no link abaixo:

https://www.networking4all.com/en/ssl+certificates/faq/server+name+indication/

Outro benefício é o CCS (Centralized Certificate Store), onde você pode armazenar seu certificado em um arquivo PFX dentro de um file server ou onde você quiser, para que seja compartilhado por 1 ou mais web servers com IIS 8.5 do Windows Server 2012 R2.

Para saber detalhes e como implementar, leia o artigo que escrevi sobre esta funcionalidade no link abaixo:

https://uilson76.wordpress.com/2014/03/24/configurando-o-centralized-certificate-store-no-iis-8-5-do-windows-server-2012-r2/

Espero que as dicas e os links possam ajudar. Qualquer outra dúvida sobre certificados digitais no IIS que não foram cobertas neste post, podem deixar seus coments ou me contatar pela minha página no facebook.

Abraços

Uilson

  1. Nenhum comentário ainda.
  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: