Certificados (certificado CA e certificado EE / Local)
Há uma pequena confusão relacionada ao certificado CA e certificado local. Eu havia feito uma pergunta semelhante antes. Desta vez, é um pouco específico.
Para autenticação usando PKI, abaixo estão as etapas.
-> Obtenha o certificado CA e carregue-o no dispositivo.
-> Gerar um par de chaves privada e pública
-> Solicitação de certificado local / EE.
Agora, as etapas seguidas para eles são:
Passo 1: solicitar segurança pki ca-certificate inscrever ca-profile entrust
Recebeu os seguintes certificados: Certificado: C = us, O = zimbro, CN = Impressão digital do primeiro oficial: 46: 71: 15: 34: f0: a6: 41: 76: 65: 81: 33: 4f: 68: 47: c4: df: 78: b8: e3: 3f Certificado: C = us, O = zimbro, CN = Impressão digital do primeiro oficial: bc: 78: 87: 9b: a7: 91: 13: 20: 71: db: ac: b5: 56 : 71: 42: ad: 1a: b6: 46: 17 Certificado: C = us, O = zimbro Impressão digital: 00: 8e: 6f: 58: dd: 68: bf: 25: 0a: e3: f9: 17: 70 : d6: 61: f3: 53: a7: 79: 10 Deseja carregar o certificado CA acima?
[sim, não] (não) sim
Pergunta: Depois que o dispositivo obtém o certificado CA do servidor CA, como o dispositivo verifica se é o servidor correto a partir da impressão digital?
Dizer sim no prompt automaticamente significa que estou confiando no certificado e verifiquei a impressão digital por algum meio OOB?
E também, o Hashing e a criptografia são feitos para todo o conteúdo do certificado ou apenas para a chave pública do servidor CA?
Etapa 2: usuário @ host> solicitar segurança pki local-certificado de inscrição certificado-id
Nesta etapa, solicitamos o certificado local depois de gerar o par de chaves.
Pergunta: Depois de obter o certificado local do servidor, como verificamos se ele é da fonte ou servidor correto e sua autenticidade?
Existe alguma descriptografia de assinatura feita? Ou ele confia nele porque configuramos esse servidor no ca-profile?
Mesmo que o decifre, o dispositivo o faz tão rápido? E também, toda a descriptografia e comparação deve ser feita manualmente por um humano?
Passo 3: Digamos que um túnel deve ser formado entre A e B. A envia o certificado local para B e B o envia para A.
Se eu não estiver errado, os certificados locais contêm suas respectivas chaves públicas.
usuário @ host> mostrar segurança pki certificado local certificado-id hello detalhe
Identificador de certificado: olá
..... Emissor: Nome comum: Exemplo-CA, Componente do domínio: local, Componente do domínio: demo Assunto: Organização: o1, Organização: o2, Unidade organizacional: ou1, Unidade organizacional: ou2, País: EUA, Estado: CA , Localidade: Sunnyvale, Nome comum: cn1, Nome comum: cn2, Componente do domínio: dc1, Componente do domínio: dc2 String do assunto: C = Exemplo, DC = dc1, DC = dc2, ST = CA, L = Sunnyvale, O = o1 , O = o2, OU = ou1, OU = ou2, CN = cn1, CN = cn2 Assunto alternativo: "usuá[email protected]", usuário.example.net, 192.0.2.1
Validade: .......
Algoritmo de chave pública: rsaEncryption (1024 bits) 30: 81: 89: 02: 81: 81: 00: b4: 14: 01: d5: 4f: 79: 87: d5: bb: e6: 5e: c1: 14
..
Algoritmo de assinatura: sha1WithRSAEncryption
Distribuição CRL:
http://example.example.net/CertEnroll/Example-CA.crl
Use para a chave: criptografia de chave, assinatura digital, 1.3.6.1.5.5.8.2.2, 1.3.6.1.5.5.8.2.2
Impressão digital: 76: a8: 5f: 65: b4: bf: bd: 10: d8: 56: 82: 65: ff: 0d: 04: 3a: a5: e9: 41: dd (sha1) 8f: 99: a4: 15: 98: 10: 4b: b6: 1a: 3d: 81: 13: 93: 2a: ac: e7 (md5)
O exemplo acima mostra um certificado local e digamos que B o receba de A.
Como, B autentica o certificado? Ou como ele sabe que veio de A?
Eu sei que há uma verificação de assinatura feita, mas o que é descriptografado e o que é comparado para provar a autenticidade do par.
Analisei os documentos, mas não me deram uma imagem clara, por isso vim aqui para obter as respostas.
Obrigado.
Respostas
Dizer sim no prompt automaticamente significa que estou confiando no certificado e verifiquei a impressão digital por algum meio OOB?
Correto, portanto, é responsabilidade do usuário verificar se esses são os certificados corretos.
E também, o Hashing e a criptografia são feitos para todo o conteúdo do certificado ou apenas para a chave pública do servidor CA?
É definitivamente possível que o certificado completo esteja em hash. Outras opções são apenas hash da estrutura subjectPublicKeyInfo ASN.1 no certificado, ou apenas o subjectPublicKey dentro dela (ou seja, a chave pública com ou sem identificador de algoritmo).
Depois de obter o certificado local do servidor, como verificamos se ele é da fonte ou servidor correto e sua autenticidade?
O protocolo de registro de certificado simples (SCEP) garante o uso de certificados confiáveis instalados na primeira etapa. Isso envolve criptografar a solicitação de certificado para a CA e verificar a assinatura após o certificado ser retornado. Tudo isso é totalmente automatizado e não requer intervenção do usuário.
Como, B autentica o certificado? Ou como ele sabe que veio de A?
Ele tem que confiar na CA que emitiu o certificado. E usa a identidade (por exemplo, o DN do assunto ou um subjectAltName, por exemplo, um FQDN ou um endereço IP) para verificar se é o host correto.
Eu sei que há uma verificação de assinatura feita, mas o que é descriptografado e o que é comparado para provar a autenticidade do par.
Existem vários aspectos para isso. O Host A fornecerá uma assinatura com sua chave privada como parte do protocolo de autenticação (por exemplo, TLS ou IKE), que B verifica com o certificado recebido de A (basicamente a assinatura é descriptografada e os dados são comparados aos dados de autenticação produzidos localmente) . O segundo aspecto é verificar se o certificado recebido é confiável. Para isso, B constrói uma cadeia de confiança para um certificado CA confiável e as assinaturas nessa cadeia são verificadas. E como mencionado acima, a identidade do host A também deve ser confirmada pelo certificado recebido.
@ecdsa deu uma ótima resposta, vou tentar responder de uma forma diferente .
Pergunta: Depois que o dispositivo obtém o certificado CA do servidor CA, como o dispositivo verifica se é o servidor correto a partir da impressão digital?
Dizer sim no prompt automaticamente significa que estou confiando no certificado e verifiquei a impressão digital por algum meio OOB?
E também, o Hashing e a criptografia são feitos para todo o conteúdo do certificado ou apenas para a chave pública do servidor CA?
Resposta curta: não tem como validar; você está dizendo à sua máquina para confiar neste CA.
Deixe-me ser filosófico por um minuto; A segurança digital é uma pilha de tartarugas, mas no fundo você tem que confiar em alguém. Por exemplo, há muitos mecanismos de segurança em meu telefone Android, mas no final do dia preciso confiar nos desenvolvedores de software que escrevem o sistema operacional e nos engenheiros que projetam o hardware para não inserir backdoors.
A ideia central do PKI é tornar essa "pilha de tartarugas" clara e transparente. Você , como usuário, diz ao seu computador "Eu confio nesta CA raiz". Isso é conhecido como "âncora de confiança". A CA raiz será usada para verificar a confiabilidade de outros objetos e entidades criptográficas, mas seu computador não tem como testar a confiabilidade da própria CA raiz. É a tartaruga de fundo.
Antes de carregar o certificado de CA raiz, você precisa ter certeza de que possui o certo. A melhor maneira é comparar manualmente (com seus próprios olhos) a impressão digital do cert (que é um hash sobre todo o conteúdo do certificado) com uma fonte confiável independente (por exemplo, compare o arquivo cert que você tem com a impressão digital da CA raiz no site do fornecedor ou peça a um funcionário do suporte para ler a impressão digital pelo telefone etc.).
Pergunta: Depois de obter o certificado local do servidor, como verificamos se ele é da fonte ou servidor correto e sua autenticidade?
Você está citando alguma saída de linha de comando de seu software, mas não nos disse que software é. A resposta a esta pergunta dependerá de qual software você está usando e como está configurado.
Analogia: quando você recebe uma nova carteira de habilitação, você envia sua foto e assinatura para o governo e um cartão volta pelo correio. Você deve verificar se a foto e a assinatura são suas (a verificação "sou eu?" ), Mas normalmente você não se preocupará em verificar se o cartão é autêntico do seu governo. O policial que o puxa verificará a autenticidade do cartão, mas normalmente você, como titular, não o fará.
Quando você obtém um novo certificado, envia sua chave pública (dentro de um arquivo CSR (Certificate Signing Request)) e receberá um certificado completo de volta. Seu software deve verificar se a chave pública no certificado corresponde à chave privada mantida localmente (a verificação "sou eu?" ), Mas normalmente não precisa verificar se o certificado está corretamente conectado a uma CA raiz confiável. Seu software específico pode fazer essa verificação, mas em geral uma máquina não precisa saber quem é o CA; por exemplo, você pode configurar o IIS para servir um determinado certificado TLS sem precisar informar ao IIS sobre a CA raiz que o emitiu. O navegador da web conectado ao seu site certamente verificará se o certificado se conecta a uma raiz na qual o navegador confia, mas isso realmente não importa para você.
Se for importante para você verificar novamente se a CA emite o certificado corretamente e se ele veio da CA que você esperava, sugiro que verifique isso manualmente usando openssl x509comandos.
O último conjunto de perguntas que você faz é sobre como funcionam as assinaturas digitais. Vale a pena fazer uma segunda pergunta, pois é um grande tópico por si só.
Temos uma resposta canônica sobre como o TLS funciona e como usa os certificados. Refiro-me a esse tópico para leitura adicional. Você não nos disse se o seu software está usando TLS ou algum outro protocolo de criptografia, mas se você entende o TLS, os outros são todos semelhantes.
- Como funciona o SSL / TLS?