Como corrigir o Firefox 59 não mais aceitando meu certificado SSL autoassinado no .dev virtualhost

20

No meu ambiente local do Apache, tenho um site que requer SSL para desenvolvimento, portanto, utilizo um certificado autoassinado. O site local funcionou bem no Firefox e Chrome até agora, mas depois de atualizar o Firefox para a versão 59 hoje não consigo aceitar a exceção de segurança (no Chrome, o certificado autoassinado continua funcionando).

O Firefox fornece essas informações adicionais na página bloqueada:

... usa um certificado de segurança inválido. O certificado não é confiável porque é autoassinado. Código de erro: SEC_ERROR_UNKNOWN_ISSUER

Não há opção para permitir a exceção aqui, como costumava existir, mas fui às Preferências do Firefox em Certificados e, na guia "Servidor", adicionei uma exceção para o domínio local. O certificado é listado no nome correto do servidor local, os detalhes mostram minhas configurações de certificado de Emitido por e Emitido como iguais, com um período de tempo válido.

Alguém experimentando problemas semelhantes com o FF 59 ou pode ter uma idéia do que tentar fazer com que o certificado autoassinado volte a funcionar localmente?

Edit: Eu não vejo nenhuma menção a isso nas notas de versão do FF 59, mas algo na nova versão faz com que todos os meus hosts virtuais locais nos domínios * .dev tentem estabelecer automaticamente uma conexão https (ou seja, todos os http solicitações para * .dev são enviadas automaticamente para o URL https). Talvez algo sobre esse comportamento também esteja causando esses problemas para meus hosts virtuais https reais.

ssl ssl-certificate firefox

— kontur
fonte

1

Meu palpite é que agora você precisa de uma CA para um certificado autoassinado, porque o Firefox tem aumentado gradualmente os requisitos nos últimos lançamentos. No entanto, com o Let's Encrypt, não há mais motivo para usar certificados autoassinados.

— Simon Greenwood

Não quero adivinhar, mas acho que @SimonGreenwood está certo. Mas normalmente o Firefox apenas define as novas opções como padrão e permite editar as configurações. Verifique suas configurações de privacidade.

@Broco Se houver algo nas configurações de segurança, não nas configurações de privacidade. Como mencionado acima, eu até adicionei uma exceção de segurança, mas o Firefox ainda insiste em não poder validar o certificado, porque obviamente o emissor é desconhecido.

— kontur

@kontur para mim o link é sobre: preferências # privacidade para definir configurações de privacidade e segurança, foi por isso que disse privacidade. Considere publicá-lo como um bug.

1

@SimonGreenwood Há muitas razões para não usar, vamos criptografar em uma conexão local. Um não seria querer configurar vamos criptografar.

— Jon Jon

15

Ainda não estou totalmente claro sobre como tudo isso se encaixa exatamente, mas, como apontado nesta resposta, os .dev domínios agora são TLDs oficiais. Dessa forma, parece que os navegadores forçam algum tipo de comportamento HSTS e forçam conexões https. Para esses TLDs, parece que meu certificado autoassinado não foi mais aceito no Firefox. Alterar meus hosts virtuais para usar .testresolveu o problema sem precisar alterar nada nos meus certificados autoassinados.

Vale ressaltar que no Firefox também meus hosts virtuais não SSL atuaram desde a versão 59 hoje, porque o comportamento do HSTS parecia forçar o SSL nos hosts virtuais que eu não havia configurado para servir via SSL. No Chrome, isso ainda funcionava, mas de qualquer forma é seguro dizer que se afastar do .devTLD agora oficialmente usado resolverá muitas dores de cabeça.

— kontur
fonte

1

Sim, .devé um TLD válido há algum tempo, portanto NÃO o use para nomear seus recursos internos. O mesmo para qualquer outro nome: não use nenhum nome que você pense que mais ninguém usará. Use os nomes de teste mencionados no RFC2606 ou apenas registre um nome de domínio verdadeiro em qualquer lugar e use um subdomínio como int.example.comou dev.example.compara sufocar todos os seus nomes internos. Você vai então nunca tem colisões ou problemas (contanto que seu não se esqueça de renovar o nome de domínio a cada ano!)

— Patrick Mevzek

2

Veja ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts

— Patrick Mevzek

1

Obrigado pelo link. As linhas de tempo mencionadas lá não se alinham, mas talvez o autor tenha falado sobre visualizações de desenvolvimento ou algo parecido. Dado o que sei agora, é realmente difícil entender por que os fornecedores de navegadores não adicionariam algumas informações adicionais sobre depuração, em particular no que diz respeito ao erro SSL nos .devdomínios. A menos que você saiba que é um TLD, não há chance de inferir que esse é o problema.

— kontur

12

Existe uma maneira fácil de contornar isso.

Vamos para about:config
Procure por "network.stricttransportsecurity.preloadlist".
Defina para false.

AVISO: Isso desativará completamente o HSTS . Dê uma olhada nos comentários sobre esta resposta para discutir algumas desvantagens deste método. Pessoalmente, acho que o benefício supera o risco, mas você é responsável por sua própria segurança.

— Andy Mercer
fonte

4

É uma péssima idéia, pois essa configuração se aplicará a todos os sites que você visitar, não apenas aos seus. Você está diminuindo sua segurança.

— Patrick Mevzek 15/03/19

Discordo. O HSTS é relativamente novo. Ficamos bem sem ele nos últimos 20 anos, por isso é exagerado dizer que desativá-lo é muito ruim para a segurança. Em segundo lugar, mesmo que seja uma má idéia, não há realmente outra opção se eu quiser que meus servidores de desenvolvimento continuem funcionando, que não envolvam mudanças muito longas no meu ambiente de desenvolvimento.

— Andy Mercer

1

Uma solução como esta: security.stackexchange.com/a/154176 afeta pelo menos apenas um site, não todos.

— Patrick Mevzek

1

Por mais condescendente que eu saiba, isso vai soar, à medida que você envelhece, perceberá que coisas como "melhores práticas" e "errado" são flexíveis e mudam com o tempo. O que as pessoas consideram "errado" agora, não foi considerado errado por muitos anos e pode não estar novamente no futuro. Quanto a essa discussão específica, teremos que concordar em discordar.

— Andy Mercer

1

Obrigado por esta correção, funciona muito bem para mim no Firefox 59.0.1 (e no Firefox Dev Edition 60). Nossos .devprojetos atuais serão transferidos para outro sufixo de TLD, mas, por enquanto, isso ajuda a não interromper o desenvolvimento local.

— Jake Bathman 19/03/19

4

Definir security.enterprise_roots.enabledcomo truena about:configpágina resolveu isso para mim e permitiu que meu certificado autoassinado funcionasse durante o desenvolvimento.

Há um pouco de discussão sobre os méritos dessa ativação por padrão aqui:
Defina security.enterprise_roots.enabled como true por padrão .

Embora a intenção desse sinalizador seja permitir que o Firefox use o armazenamento raiz da CA em toda a máquina como uma fonte válida para as autoridades de certificação, isso corrigiu a situação do meu próprio caso de uso em que eu tenho um certificado de vários domínios autoassinado que eu uso localmente para teste (subjectAltName's) . Mesmo depois de adicionar o certificado à lista de certificados do Firefox, não foi até eu ativar isso que permiti o carregamento do site local.

— Sean Aitken
fonte

Obrigado, funcionou!

— informatik01

0

Teve o mesmo problema no Basilisk Web Browser . Tentei alterar as configurações de proxy de rede ou modificar os sinalizadores "network.stricttransportsecurity.preloadlist" ou "security.enterprise_roots.enabled" ... mas não resolveu o botão ausente para adicionar certificado para o site bloqueado. Somente isso conseguiu:

Vá para about:support.
Clique Open Directoryno seu perfil do navegador.
Feche o navegador completamente.
Edite o arquivo " SiteSecurityServiceState.txt " no diretório acima.
Encontre e remova a linha inteira que contém o site HSTS bloqueado.
Salve o arquivo e reabra o navegador nesse site.

— Noam Manos
fonte

-3

Eu fui para "Let's Encrypt"

https://letsencrypt.org/

Válido apenas por três meses por vez, mas a atualização pode ser automatizada.

Como você pode ver nas observações, há um problema. Nossos domínios de desenvolvimento e teste são chamados dev-www.example.com e test-www.example.com. Usamos o certificado curinga da produção.

— Gerard H. Pille
fonte

5

A criptografia Let's não depende do servidor e do domínio estarem disponíveis ao público? Estou procurando opções para usar SSL em hosts virtuais locais.

— kontur

Sim, isso não funciona para pessoas que estão desenvolvendo localmente.

— 21718 Andy Mercer

a pergunta é sobre DEV LOCAL

@ Pieter é o mesmo que "desenvolvimento local"? Porque é isso que fazemos.

— Gerard H. Pille

1

@ GerardH.Pille Você só pode gerar Vamos criptografar certificados se o servidor estiver acessível na Internet. Para o meu desenvolvimento local, esse não é o caso, portanto, não é viável. Por favor, informe se há algo que me falta.

— kontur