Eu tive que descobrir os certificados autoassinados no Windows, combinando partes das respostas fornecidas e outros recursos. Aqui está o meu próprio (e espero que completo) passo a passo. Espero que poupe um pouco da minha dolorosa curva de aprendizado. Ele também contém informações sobre tópicos relacionados que aparecerão mais cedo ou mais tarde quando você criar seus próprios certificados.
Crie um certificado autoassinado no Windows 10 e abaixo
Não use makecert.exe. Foi preterido pela Microsoft.
A maneira moderna usa um comando do PowerShell.
Windows 10:
Abra o PowerShell com privilégios de administrador:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Dev Cert *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)
Windows 8, Windows Server 2012 R2:
No Powershell nesses sistemas, os parâmetros -FriendlyName e -NotAfter não existem. Simplesmente remova-os da linha de comando acima.
Abra o PowerShell com privilégios de administrador:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
Uma alternativa é usar o método para a versão mais antiga do Windows abaixo, que permite usar todos os recursos do Win 10 para criação de certificados ...
Versões mais antigas do Windows:
Minha recomendação para versões mais antigas do Windows é criar o certificado em uma máquina Win 10, exportá-lo para um arquivo .PFX usando uma instância mmc (consulte "Confiar no certificado" abaixo) e importá-lo para o armazenamento de certificados na máquina de destino com o sistema operacional Windows antigo. Para importar o certificado, NÃO clique com o botão direito do mouse. Embora exista um item "Importar certificado" no menu de contexto, todas as minhas tentativas falharam em usá-lo no Win Server 2008. Em vez disso, abra outra instância mmc na máquina de destino, navegue até "Certificados (Computador Local) / Pessoal / Certificados" , clique com o botão direito do mouse no painel do meio e selecione Todas as tarefas → Importar.
O certificado resultante
Ambos os comandos acima criam um certificado para os domínios localhost
e *.dev.local
.
A versão Win10 também possui um tempo de vida útil de 15 anos e um nome de exibição legível "Dev Cert * .dev.local, dev.local, localhost".
Atualização: Se você fornecer várias entradas de nome de host no parâmetro -DnsName
(como mostrado acima), a primeira dessas entradas se tornará o Assunto do domínio (Nome Comum AKA). A lista completa de todas as entradas de nome de host será armazenada no campo Nome Alternativo do Assunto (SAN) do certificado. (Obrigado a BenBewards por apontar isso.)
Após a criação, o certificado estará imediatamente disponível em todas as ligações HTTPS do IIS (instruções abaixo).
Confie no certificado
O novo certificado não faz parte de nenhuma cadeia de confiança e, portanto, não é considerado confiável por nenhum navegador. Para mudar isso, copiaremos o certificado no armazenamento de certificados das CAs raiz confiáveis em sua máquina:
Abra mmc.exe, Arquivo → Adicionar / Remover Snap-In → escolha "Certificados" na coluna esquerda → Adicionar → escolha "Conta do Computador" → Avançar → "Computador Local ..." → Concluir → OK
Na coluna da esquerda, escolha "Certificados (Computador Local) / Pessoal / Certificados".
Encontre o certificado recém-criado (no Win 10, a coluna "Nome amigável" pode ajudar).
Selecione este certificado e pressione Ctrl-C para copiá-lo para a área de transferência.
Na coluna esquerda, escolha "Certificados (computador local) / CAs / certificados raiz confiáveis".
Pressione Ctrl-V para colar seu certificado nesta loja.
O certificado deve aparecer na lista de autoridades raiz confiáveis e agora é considerado confiável.
Use no IIS
Agora você pode acessar o Gerenciador do IIS, selecionar as ligações de um site local → Adicionar → https → inserir o nome do host do formulário myname.dev.local
(seu *.dev.local
certificado é válido apenas ) e selecionar o novo certificado → OK.
Adicionar aos hosts
Adicione também o nome do seu host a C: \ Windows \ System32 \ drivers \ etc \ hosts:
127.0.0.1 myname.dev.local
Feliz
Agora, o Chrome e o IE devem tratar o certificado como confiável e carregar o site quando você abrir https://myname.dev.local
.
O Firefox mantém seu próprio armazenamento de certificados. Para adicionar seu certificado aqui, você deve abrir seu site no FF e adicioná-lo às exceções quando o FF o avisar sobre o certificado.
Para o navegador Edge, pode haver mais ação necessária (veja mais abaixo).
Teste o certificado
Para testar seus conhecimentos, o Firefox é sua melhor escolha. (Acredite, eu também sou fã do Chrome, mas FF é melhor nesse caso.)
Aqui estão os motivos:
- O Firefox usa seu próprio cache SSL, que é eliminado na recarga de turno. Portanto, qualquer alteração no conteúdo de seus sites locais será refletida imediatamente nos avisos do FF, enquanto outros navegadores podem precisar de uma reinicialização ou de uma limpeza manual do cache SSL do Windows.
- Além disso, o FF fornece algumas dicas valiosas para verificar a validade do seu certificado: Clique em Avançado quando o FF mostrar seu aviso de certificado. O FF mostrará um pequeno bloco de texto com um ou mais avisos possíveis nas linhas centrais do bloco de texto:
O certificado não é confiável porque é autoassinado.
Este aviso está correto! Como observado acima, o Firefox não usa o armazenamento de certificados do Windows e confiará apenas neste certificado, se você adicionar uma exceção. O botão para fazer isso está logo abaixo dos avisos.
O certificado não é válido para o nome ...
Este aviso mostra que você fez algo errado. O domínio (curinga) do seu certificado não corresponde ao domínio do seu site. O problema deve ser resolvido alterando o (sub-) domínio do site ou emitindo um novo certificado que corresponda. Na verdade, você pode adicionar uma exceção no FF, mesmo que o certificado não corresponda, mas você nunca obteria um símbolo de cadeado verde no Chrome com essa combinação.
O Firefox pode exibir muitos outros avisos de certificação agradáveis e compreensíveis neste local, como certificados expirados, certificados com algoritmos de assinatura desatualizados etc. Não encontrei outro navegador que me desse esse nível de feedback para solucionar qualquer problema.
Qual padrão de (sub) domínio devo escolher desenvolver?
No comando New-SelfSignedCertificate acima, usamos o domínio curinga *.dev.local
.
Você pode pensar: por que não usar *.local
?
Motivo simples: é ilegal como um domínio curinga.
Os certificados curinga devem conter pelo menos um nome de domínio de segundo nível.
Portanto, os domínios do formulário *.local
são bons para desenvolver sites HTTP. Mas não muito para HTTPS, porque você seria forçado a emitir um novo certificado correspondente para cada novo projeto iniciado.
Notas laterais importantes:
- Domínios de host válidos podem conter SOMENTE letras a z, dígitos, hífens e pontos. Não são permitidos sublinhados! Alguns navegadores são muito exigentes quanto a esses detalhes e podem dificultar quando se recusam a corresponder seu domínio
motör_head.dev.local
ao seu padrão curinga *.dev.local
. Eles cumprirão quando você alternar para motoer-head.dev.local
.
- Um curinga em um certificado corresponderá apenas a UM rótulo (= seção entre dois pontos) em um domínio, nunca mais.
*.dev.local
corresponde, myname.dev.local
mas NÃO other.myname.dev.local
!
- Curingas de vários níveis (
*.*.dev.local
) NÃO são possíveis em certificados. Portanto, other.myname.dev.local
só pode ser coberto por um curinga do formulário *.myname.dev.local
. Como resultado, é melhor não usar uma parte do domínio de quarto nível. Coloque todas as suas variações na parte do terceiro nível. Dessa forma, você se dará bem com um único certificado para todos os seus sites de desenvolvimento.
O problema com o Edge
Não se trata realmente de certificados autoassinados, mas ainda relacionados a todo o processo:
Após seguir as etapas acima, o Edge pode não mostrar nenhum conteúdo quando você abre myname.dev.local
.
O motivo é um recurso característico do gerenciamento de rede do Windows 10 para aplicativos modernos, chamado "Isolamento de rede".
Para resolver esse problema, abra um prompt de comando com privilégios de administrador e digite o seguinte comando uma vez:
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Mais informações sobre o isolamento de borda e rede podem ser encontradas aqui:
https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
makecert.exe
para estar no meu caminho. Para os certificados, pensei que seria mais seguro e usar-a SHA512 -len 8192
- demorou uma eternidade para gerar. E como eu suspeitava, não teve impacto sobre o nível de criptografia usado pelo IIS. Por padrão, o IIS usa 128 bits, você precisa fazer coisas de diretiva de grupo para alterar isso. Nota adicional para outros leitores: não altere os números mágicos depois-eku
, eles são necessários.