Certificado curinga autoassinado

Eu tenho o pihole configurado em casa, então eu quero poder lidar com solicitações de qualquer site com meu próprio servidor, para mostrar uma página "este site foi bloqueado".

Estou tentando fazer isso criando um certificado autoassinado para qualquer URL e instalando-o no meu dispositivo. Os comandos que usei para gerar o certificado:

openssl genrsa 2048 > pihole.key
openssl req -new -x509 -nodes -days 36500\
    -key pihole.key \
    -subj "/C=NL/ST=Utrecht, Inc./CN=*" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:*,DNS:*")) \
    -out pihole.cert
openssl x509 -noout -fingerprint -text < pihole.cert > pihole.info
cat pihole.cert pihole.info > pihole.pem
service apache2 reload

Eu instalei este certificado no meu dispositivo Windows, e o Windows mostra que é um certificado válido.

No entanto, o chrome me dá um NET::ERR_CERT_COMMON_NAME_INVALIDe o edge me dá um erro semelhante ( DLG_FLAGS_SEC_CERT_CN_INVALID)

Por que é isso? É CN = *apenas não é permitido? Como eu consegui o que quero?

ssl certificate

— Daniël van den Berg
fonte

Como uma observação lateral: para os principais sites, seu navegador provavelmente não aceitará nenhum certificado que você conseguir gerar. Esses sites usam a fixação de certificados e enviam impressões digitais de seus certificados TLS para inclusão nesses navegadores. Seu certificado não corresponderá à impressão digital armazenada e será bloqueado. Aqui está mais informações: noncombatant.org/2015/05/01/about-http-public-key-pinning

— Martijn Heemels

certificados autoassinados podem ser problemáticos, como você descobriu. Em vez disso, você pode obter uma certificação "adequada" no letsencrypt.org - eles são gratuitos e oferecem suporte a caracteres curinga. Dependendo de quantos hosts você estava tentando cobrir com isso * você realmente precisa, um (ou mais) certificados de letsencrypt pode cobrir você #

— Dave Smylie #

@DaveSmylie é para um bloqueador de anúncios, eu não possuo os domínios.

— Daniël van den Berg

@ Stewart, leia meu comentário anterior.

— Daniël van den Berg

Observe também: se você estiver usando isso para um bloqueador de anúncios, talvez seja melhor soltar silenciosamente as conexões com os servidores relevantes, em vez de mostrar uma página alternativa. Como 90% dos anúncios modernos são carregados inicialmente por meio de JavaScript, é improvável que sua página alternativa tenha visibilidade real na página. Provavelmente, isso vai quebrar as coisas, na verdade, tentando carregar recursos não JavaScript como Javascript.

— Nzall

Respostas:

Não é permitido. Como uma adição específica de protocolo à validação padrão de nome de host TLS, todos os principais navegadores da Web (clientes HTTPS) concordaram basicamente em restringir os certificados curinga ao "eTLD + 1" - ou seja, deve haver um "TLD efetivo" mais um componente -card.

Geralmente, isso significa exigir pelo menos dois componentes (*.example.net está bom, mas *.netnão está, nem está vazio *). A regra "TLD efetivo" expande isso para sufixos de vários níveis, já co.ukque as pessoas usam como "TLDs" indivisíveis na prática. (Portanto, *.example.ac.uké permitido, mas *.ac.uknão é.)

Você pode inspecionar como a lista pública de sufixos é implementada no Chromium e no Mozilla .

Consulte a discussão relacionada no Security.SE, que tem uma citação dos Requisitos de linha de base do fórum do navegador CA (que se aplicam apenas a autoridades de certificação WebPKI públicas, mas ainda refletem a implementação geral):

As CAs revogarão qualquer certificado em que o caractere curinga ocorra na primeira posição do rótulo imediatamente à esquerda de um rótulo "controlado por registro" ou "sufixo público".

Para evitar essa restrição, crie uma autoridade de certificação que emita certificados "sob demanda" para qualquer site que você tentar visitar. Não sei como isso seria implementado em qualquer servidor Web comum, mas esse é um método comum usado por sistemas comerciais de interceptação TLS; programas antivírus e outros malwares; e ferramentas de desenvolvimento, como o pacote Burp Proxy.

Por exemplo, o servidor da web OpenResty (basicamente Nginx-with-Lua) tem uma ssl_certificate_by_luaopção para implementar a geração dinâmica de certificados. O proxy Squid suporta a imitação de certificado em seu recurso ssl-bump.

Observe também que as SANs substituem completamente o Subject-CN se ambas estiverem presentes. Isso torna a inclusão do CN principalmente redundante (a menos que o software do cliente seja tão antigo que não tenha suporte à SAN) e, para navegadores da CA públicos, nem sequer o aceitam mais.

— user1686
fonte

Eu já descobri empiricamente esse limite de TLD + 1 aqui em um projeto anteriormente. Obrigado por colocá-lo para fora. 1

— Rui F Ribeiro

Obrigado pela sua resposta elaborada, acho que isso explica sim. Você conhece uma abordagem diferente que eu poderia usar?

— Daniël van den Berg

Promovido o posicionamento estratégico de "e outros malwares".

— Džuris 13/11/18

@ DaniëlvandenBerg: Por acaso sugeri um no próprio post. Acabei de adicionar links para exemplos de Nginx e Squid.

— user1686

Só pode haver um caractere curinga em um certificado (ou seja, não *.*.example.com), pode corresponder apenas a um único rótulo (ou seja www, somente não www.example.com), pode estar apenas na posição mais à esquerda (ou seja, *.www.example.commas não www.*.example.com) e não pode estar dentro do sufixo público (ou seja, não *.com).

— Steffen Ullrich
fonte