Etapas para produzir um certificado auto-assinado que, depois de ser confiável, funcionará para dois IPs diferentes sem um aviso de segurança

Question

Temos um servidor de teste que estou tentando mudar para HTTPS / SSL e tem um IP interno e um IP externo. Temos que usar certificados autoassinados para esse servidor específico. Houve uma vez no passado que fiz algumas P & D no RTMPS com o Flash, e ainda tinha uma lista de etapas para criar um certificado autoassinado para o IP interno e colocá-lo no repositório confiável em máquinas clientes.

Dito isso, preciso que isso funcione simultaneamente para os IPs internos e externos. Quando tento usar as mesmas etapas para produzir e confiar em um certificado para o IP externo, o servidor continua tentando enganar o certificado do IP interno, mesmo quando o cliente usa o IP externo. Isso aparentemente tem algo a ver com ele passando pelos cabeçalhos HTTP e obtendo o certificado para o site padrão. Portanto, mesmo que o certificado do IP externo seja confiável, a máquina do cliente continuará gerando um aviso de segurança ao navegar para o site no IP externo.

Completamente lançando minhas anotações anteriores sobre como fazer isso com o IP interno de lado, como isso pode ser tratado simulatenously para um IP interno e externo? Como você pode usar certificados auto-assinados para ambos os IPs, sem gerar um aviso de segurança no navegador do cliente?

Observe que isso não é uma duplicação. Eu entendo que existem informações sobre os Nomes Alternativos de Assunto, certificados de caractere curinga etc. No entanto:

1. Grande parte é para o Apache; Estou usando o IIS 7.

2. Muito disso é para o Linux; Estou usando o Windows.

3. Ele também tende a lidar com nomes de domínio, que parecem ser necessários para certificados curinga; Estou usando apenas IPs.

4. Parte do que resta neste ponto espera que eu tenha opções no IIS ou no Windows que não estão disponíveis universalmente.

5. As poucas peças que restam podem estar um pouco acima da minha cabeça, e as etapas que elas usam esperam algum conhecimento pré-existente que simplesmente não está lá. Em outras palavras, eles pularam etapas, pularam para tópicos avançados, etc.

O que é uma lista clara de etapas para fazer isso, supondo que o servidor seja o IIS 7 / Windows Server 2008 R2 e que as máquinas cliente usem o Windows 7 (às vezes, o Windows Embedded Standard) e versões diferentes do IE? Os clientes estão acessando as páginas, os serviços da Web e os endereços IP, e eu tenho usado o OpenSSL (embora esteja aberto a outras opções). Obrigado.

    

Answer 1

Veja a resposta de Massimo para o modo Direito de fazê-lo.

Caso contrário, você pode adicionar IPs à SAN do certificado criando um arquivo de configuração com o seguinte (mais quaisquer outras opções desejadas):

[ v3_ca ]
subjectAltName = IP:1.2.3.4

Ou se você tiver vários IPs ...

[ v3_ca ]
subjectAltName = @alt_names

[alt_names]
IP.1 = 1.2.3.4
IP.2 = 2.3.4.5
IP.3 = 3.4.5.6

Em seguida, emita o comando normal do OpenSSL para criar o certificado com as seguintes adições:

-extfile configuration_file_mentioned_above.cnf -extensions v3_ca

Observação: a linha acima geralmente começa com openssl x509 -req se você estiver com problemas.

O arquivo de configuração mais simples e válido seria algo assim (salvei isso como example.cfg ):

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca

[ req_distinguished_name ]
commonName = TypeCommonNameHere

[v3_ca]
subjectAltName = @alt_names

[alt_names]
IP.1 = 203.0.113.1
IP.2 = 192.0.2.1
IP.3 = 198.51.100.1

Em seguida, execute:

openssl req -x509 -nodes -days 3653 -newkey rsa:2048 -keyout example.key -out example.pem -config example.cfg

Ele pedirá o nome comum para o certificado e escreverá example.key e example.pem com as chaves privada e pública (respectivamente). Além disso, você tem que colocar os IPs no arquivo de configuração, mas não pode colocar o nome comum lá (você pode, mas ainda precisa digitá-lo quando o OpenSSL solicitar).

Além disso, este exemplo usa um arquivo de configuração inteiro, em que a resposta original supõe que você já tinha um arquivo de configuração e o aumentava com as informações de SAN de um arquivo de configuração de extensão (provavelmente é mais confuso, mas a razão pela qual não usou os argumentos dados na resposta original)

    

Answer 2

Você realmente não deveria estar usando endereços IP em um certificado SSL; você deve configurar uma infra-estrutura de DNS adequada para que você tenha f.e. internal.yourdomain.com apontando para o endereço IP interno e external.yourdomain.com apontando para o externo; então você terá que colocar os dois nomes como Subject Alternative Names no certificado, e ele funcionará perfeitamente.

Dito isto, você pode usar endereços IP como SANs; mas exatamente como isso pode ser feito depende da ferramenta que você está usando para solicitar o certificado e da autoridade de certificação que o emitirá.

Em ambos os casos, você deve usar um certificado único com duas SANs; usar dois certificados não faz sentido e nem funcionaria, porque você não pode vincular dois certificados diferentes ao mesmo site.

    

Answer 3

Se você tiver dois endereços IP ou nome, precisará de duas certs e duas definições https. No Apache httpd, isso seria duas seções vhost.