Estou tentando trabalhar com a API OpenSSL C, ainda sou relativamente novo em tudo isso e encontro muitas informações misturadas por aí, então eu acho que é sensato pedir idéias / opiniões / esclarecimentos.
De qualquer forma, o programa cliente requer que um certificado ou diretório seja carregado contendo um “TrustStore”. Este é apenas outro significado para o O próprio certificado CA do servidor, no caso de eu estar criando meus próprios certificados SSL para o referido servidor?
E se sim, a CA intermediária funcionará para esse fim em substituição à CA raiz?
Acho que estou no caminho certo. No entanto, eu só queria alguns esclarecimentos para evitar cometer algum erro estúpido real, pois ouvi algumas informações conflitantes em relação a isso. Alguns dizem que o cliente precisa da própria CA raiz; outras fontes dizem que instalam apenas CA intermediária razões de segurança, o que parece lógico.
No entanto, geralmente fico um pouco confuso sobre como a cadeia de confiança funciona em relação a uma conexão de cliente. Na verdade, eu só precisei gerar um CSR e instalar um certificado no servidor da web, então as coisas do lado do cliente são meio novas para mim.
Esta pergunta foi originalmente feita aqui no Stack Overflow, foi sugerido que eu perguntasse à comunidade do setor de informações.
Comentários
- Acho que você está usando a frase errada: um certificado autoassinado é um certificado em que o certificado do emissor é o próprio certificado. Você provavelmente significa um certificado que é assinado pela sua própria CA. Neste caso: a CA raiz é geralmente colocada no armazenamento confiável e o certificado intermediário assinado pela CA raiz e o certificado folha assinado pelo certificado intermediário são enviados durante o handshake TLS .
- Possível duplicata de Como o SSL / TLS PKI funciona?
Resposta
tl; dr Se o certificado contiver alguma variação de CA:TRUE, faz sentido distribuí-lo; caso contrário, não há benefício em distribuí-lo.
A própria cadeia de confiança pode ser explicada em termos da estrutura do certificado.
Se começarmos com o certificado do seu servidor (ou seja, o certificado que você normalmente usaria para o apache):
- o certificado do seu servidor é gerado por uma autoridade de certificação, com base em um CSR que você fornece. Esse CSR contém sua chave pública e algumas outras informações que a CA pode ou não estar interessada em usar.
- a CA recebe seu CSR e (geralmente), criará um certificado assinado usando uma CA intermediária. Seu certificado terá duas chaves públicas: uma para o assunto (que é a chave pública extraída de seu CSR) e uma para a parte emissora, que é o certificado intermediário da CA “.
- a CA” O próprio certificado intermediário é um certificado assinado (com algumas opções especiais), em que a chave do assunto será a chave pública da CA intermediária (que é a mesma chave pública encontrada na Chave Pública do emissor do certificado do servidor). A chave de assinatura (ou emissão) será o certificado raiz da CA (alternativamente, será outro intermediário).
- o certificado raiz da CA é (geralmente) um certificado autoassinado. Na prática, isso significa que as chaves do emissor e do assunto são a mesma chave pública.
Você pode ver isso verificando os certificados em estado selvagem, por exemplo:
$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority A cadeia de confiança que essa construção pode ser resumida como (estou começando pelo ” bottom “- o certificado Equifax):
- a CA raiz (Equifax) delega as atividades do dia-a-dia a uma CA intermediária (GeoTrust) e assina um certificado representando esse fato (ou seja, definindo CA: TRUE, KeyUsage: keyCertSign). Em outras palavras, a CA raiz “confia” no intermediário para emitir certificados em seu nome (espero que depois de concluir uma série de etapas de validação obrigatórias).
- nesta cadeia, o intermediário (Geotrust) delegou ainda a um CA do Google (CN = Google Internet Authority G2).
- o delegado (também conhecido como CA intermediário do Google), então, assina um CSR, que efetivamente é um documento que declara que para um conjunto de nomes (t o CN e, possivelmente, os nomes alternativos do assunto), um par de chaves privada / pública é válido / confiável (a confiança aqui vem do fato de eles terem validado a declaração de falar por um determinado nome – neste caso, a CA do Google emitiu um certificado para * .google.com).
Observe que (raiz) CAs são geralmente autoassinados – uma CA é geralmente confiável porque obedece a um conjunto de processos e procedimentos que garantem que não emite certificados para as pessoas quem não deveria tê-los. É por isso que não posso sair e conseguir um certificado dizendo que sou o Google.Esta é, portanto, uma espécie de convenção (embora apoiada por mecanismos formais), e se você iniciar sua própria CA, distribuir seus certificados raiz (e intermediários) atinge exatamente o mesmo que distribuir certificados de outras CAs: faz com que os certificados sejam emitidos por esse CA ser aceito como válido (ou seja, confiável) pelo sistema.
Em termos mais práticos, o armazenamento confiável (para openSSL) é basicamente um monte de arquivos com uma convenção de nomenclatura específica. Veja https://www.openssl.org/docs/faq.html#USER5 :
Quando um certificado é verificado se sua CA raiz deve ser “confiável” pelo OpenSSL. Isso normalmente significa que o certificado CA deve ser colocado em um diretório ou arquivo e o programa relevante configurado para lê-lo
Esse diretório é / etc / ssl / certs (existem outros, como / etc / pki em RH-likes).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 fornece uma visão geral de como adicionar um certificado à loja, como https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
A versão curta é que update-ca-certificates automatiza o processo e é a ferramenta comumente usada.
A versão um pouco mais longa é que os certificados precisam ser armazenados por hash (por exemplo, em arquivos nomeados com base na saída de openssl x509 -hash -in cert.pem), para que o openSSL possa validar as cadeias com eficiência.
Consulte https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html para obter informações adicionais.
atualizado para responder às perguntas nos comentários:
O certificado do servidor , nesta discussão, é definido como confiável ou não com base em sua cadeia de confiança. Se você pensar sobre como (por exemplo) curl https://google.com funciona, é um pouco mais fácil de entender:
- curl abre uma conexão TLS com o google, que retorna um certificado.
- curl olha para aquele certificado de “usuário final” – isto é, o certificado do servidor, e procura especificamente pelo emissor.
- se o emissor é “conhecido” em o armazenamento confiável, o restante da cadeia de confiança é validado (isto é, o certificado do emissor do certificado do servidor é verificado, e se ele tiver um emissor diferente dele, esse emissor é verificado, etc). Somente se a cadeia de confiança total puder ser validada é que o certificado é considerado válido.
No entanto, seria absolutamente impraticável distribuir cadeias de confiança se os certificados do usuário final precisassem ser incluídos. Eu não tenho números sobre quantos sites existem, mas com base no fato de Alexa fornecer um 1M principal, você diria que é mais de 1 milhão.
Qual é o objetivo de uma cadeia de confiança: geralmente você precisa ter os certificados do emissor por perto, mas não precisa que os certificados finais sejam distribuídos, porque eles informam quem é o emissor.
E você pode verificar se eles não são ” mentindo, porque você pode verificar a chave pública do emissor (e a cadeia de confiança que a estabelece é a chave adequada) e validar se o certificado do usuário final (isto é, servidor) foi realmente assinado pela contraparte privada do emissor chave pública.
Portanto, não, você não deve distribuir os certificados do usuário final, mas apenas a cadeia de confiança – ou, em termos mais simples: distribua todos os certificados gerados onde as BasicConstraints (legitimamente) dizem algo pelo menos CA: TRUE. Não distribua nada que não atenda a essa condição, porque é uma perda de tempo e espaço em disco – tudo que não diz CA: TRUE pode ser validado contra algo que diz.
Comentários
Resposta
Um certificado autoassinado é exatamente isso: é assinado meu próprio (é sua própria âncora de confiança).
Portanto, para ser confiável, ele precisa ser manualmente e explicitamente colocado na lista de âncoras confiáveis do aplicativo. Como isso é feito depende do sistema operacional e do aplicativo.
Por exemplo, se você estiver usando o armazenamento de certificado interno do Windows, precisará colocar esse certificado autoassinado no armazenamento de “autoridade de certificação raiz confiável” ou o certificado não será aceito. OpenSSL usa um sistema de armazenamento específico de aplicativo diferente: você também precisará instalar o certificado como uma CA confiável, mas como fazer isso depende muito de qual aplicativo e sistema operacional você está usando (consulte este artigo para algumas instruções genéricas).
Comentários
- Isso significa que " Trust Store " certificado é o mesmo que aquele instalado no Apache, por exemplo? Isso ' s a parte que é mais confusa, i ' ma
GNU/Linuxusuário, cujo diretório eu precisava vincular no aplicativo cliente, era/etc/ssl/certs. No entanto, não consegui encontrar uma explicação clara do que exatamente é o processo desse lado das coisas. Pelo menos você entendeu minha pergunta aqui, o ponto principal por trás disso é escrever o cliente e fazer com que ele confie no servidor ao qual está se conectando. - O que eu ' estou tentando fazer exatamente é criar um CA, e acho que o certificado é assinado pelo CA (intermediário), então, nesse caso, isso significa que o CA é a âncora de confiança, portanto o Ca intermediário deve ser instalado no diretório de certificados confiáveis? Obrigado por responder.
- Sua pergunta, portanto, é mais geral. Eu ' propus fechá-lo com um link para a resposta que você procura.
/etc/ssl/certsdiretório? Como todos eles contêm as chaves públicas?