Certbot: Precisa de suporte a certificados curinga | Conflito de interesse com CAs?

Criado em 4 jan. 2016  ·  4Comentários  ·  Fonte: certbot/certbot

Oi,

De acordo com esta edição , 51 participantes falaram sobre o suporte - ou não - de certificados curinga com sua oferta Let's Encrypt.
Acredito que seja um número enorme e precisamos:

  • os documentos de pesquisa que mostram a evidência no fato de que os certificados curinga enfraquecem a segurança do TLS, como você disse;
  • a explicação de por que não é um conflito de interesses negociado com um de seus primeiros patrocinadores - e seu parceiro mais forte também - chamado IdenTrust : foi o acordo para enfraquecer a segurança de sua oferta e não oferecer certificados curinga para evitar a canibalização do Mercado CA?

Obrigado,
HLFH

Comentários muito úteis

@bmw Alguma opinião sobre isso? Talvez empurrar uma atualização para # 66 ou até mesmo desbloqueá-la para que as pessoas saibam o que está acontecendo? Também estou executando ping em @bdaehlie, que bloqueou e fechou # 66, respectivamente.

Eu mesmo olhei para a especificação para ver se havia algum movimento nos curingas e vi exatamente a mesma coisa mencionada por @MichaelHierweck (embora agora esteja na Seção 6.5 no rascunho mais recente).

Especialmente considerando que este projeto não é mais apenas letsencrypt , mas agora certbot o protocolo deve ser totalmente suportado e não limitado por um único provedor que não segue as especificações. A política de emissão é difícil, mas a implementação da especificação é menos difícil. Eu presumo que o certbot apenas geraria algum tipo de mensagem de erro se alguém tentasse obter um caractere curinga emitido por letsencrypt.

Como um aparte pessoal, espero que apoiar isso no cliente e empurrar a culpa _propriadamente_ para o lado do servidor LE / ca os leve a permitir curingas, pois tornaria alguns projetos em que estou trabalhando consideravelmente mais fáceis.

Todos 4 comentários

@HLFH ,

Este repositório é para o cliente Let's Encrypt, que segue o protocolo ACME, que não permite certificados curinga. Como a adição desse recurso está fora do escopo do cliente, encerrarei este problema. Fique à vontade para fazer o acompanhamento com o grupo de trabalho da IETF para a ACME. Você pode encontrar mais informações na página do github .

Alguém poderia explicar o que ACME Seção 6.6 significa neste contexto:

Cabe à política local do servidor decidir quais nomes são
aceitável em um certificado, dadas as autorizações que o servidor
associa-se à chave da conta do cliente. Um servidor PODE considerar um
cliente autorizado para um domínio curinga se for autorizado para o
nome de domínio subjacente (sem o rótulo "*").

O PR 14, mesmo não fundido, expressa isso de forma mais clara.

Pelo que entendi, isso permitiria ao LE autorizar um cliente para um domínio (como: example.com) e emitir certificados curinga (como: * .example.com) posteriormente da perspectiva da especificação ACME.

Parece que a falta de suporte a curingas estava relacionada à política local do servidor. Em caso afirmativo, declare claramente que a política da LE se opõe (atualmente) à emissão de certificação curinga e pare de culpar o ACME WG. :)

Se eu estiver errado, agradeço antecipadamente pelo esclarecimento. :)

@bmw Alguma opinião sobre isso? Talvez empurrar uma atualização para # 66 ou até mesmo desbloqueá-la para que as pessoas saibam o que está acontecendo? Também estou executando ping em @bdaehlie, que bloqueou e fechou # 66, respectivamente.

Eu mesmo olhei para a especificação para ver se havia algum movimento nos curingas e vi exatamente a mesma coisa mencionada por @MichaelHierweck (embora agora esteja na Seção 6.5 no rascunho mais recente).

Especialmente considerando que este projeto não é mais apenas letsencrypt , mas agora certbot o protocolo deve ser totalmente suportado e não limitado por um único provedor que não segue as especificações. A política de emissão é difícil, mas a implementação da especificação é menos difícil. Eu presumo que o certbot apenas geraria algum tipo de mensagem de erro se alguém tentasse obter um caractere curinga emitido por letsencrypt.

Como um aparte pessoal, espero que apoiar isso no cliente e empurrar a culpa _propriadamente_ para o lado do servidor LE / ca os leve a permitir curingas, pois tornaria alguns projetos em que estou trabalhando consideravelmente mais fáceis.

Pessoalmente, acho que o nº 66 foi resolvido corretamente apontando as pessoas para https://community.letsencrypt.org. Quanto a atualizá-los, acho que não há nada a ser dito. A frase

Um servidor PODE considerar um cliente autorizado para um domínio curinga se for autorizado para o nome de domínio subjacente (sem o rótulo "*").

não é novo e remonta a letsencrypt / acme-spec # 166. Eu estava incorreto quando disse que não era permitido nas especificações ACME.

Dito isso, criei o nº 3233 para rastrear o problema de permitir que os usuários solicitem certificados curinga no cliente.

Esta página foi útil?
0 / 5 - 0 avaliações