Tenho a resposta .tsr de um processo de assinatura no OpenSSL. openssl ts -replyfunciona.
openssl ts -reply -in b1.tsr -text
Using configuration from g:/progs/openssl/ssl/openssl.cnf
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified
TST info:
Version: 1
Policy OID: 1.3.6.1.4.1.6449.2.1.1
Hash Algorithm: sha256
Message data:
0000 - 10 20 96 d8 03 ec ed 6e-03 56 3d d6 d6 a7 14 50 . .....n.V=....P
0010 - b0 a7 53 a9 34 4e b9 57-f7 e2 83 13 5e 0d df e0 ..S.4N.W....^...
Serial number: 0xA7ADC6135D0A39500F7C3B0C41578D8C2CB62B87
Time stamp: Jun 22 10:59:44 2019 GMT
Accuracy: unspecified
Ordering: no
Nonce: 0xD4154ECA4E9A0D06
TSA: DirName:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Time Stamping Signer #1
Extensions:
openssl ts -verifyfalha.
openssl ts -verify -sha256 -digest "102096d803eced6e03563dd6d6a71450b0a753a9344eb957f7e283135e0ddfe0" -in b1.tsr -CAfile comodo.pem
Verification: FAILED
11928:error:2F06D064:time stamp routines:TS_VERIFY_CERT:certificate verify error:.\crypto\ts\ts_rsp_verify.c:264:Verify error:unable to get local issuer certificate
O que é isso sobre certificado de emissor local? Não consigo usar -noverify no comando "ts".
Responder1
Para construir uma cadeia de certificados completa para o openssl verificar, você não precisa apenas do certificado raiz (que você especificou usando o -CAfileswitch), mas também do certificado que foi usado para assinar o TSResponse.
Na página de manual de ts:
-untrusted cert_file.pem
Set of additional untrusted certificates in PEM format which may be needed when building the certificate chain for the TSA's signing certificate. This
file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them. (Optional)
Responder2
Um erro de verificação "incapaz de obter o certificado do emissor local" significa que o OpenSSL não foi capaz de encontrar no armazenamento confiável local a raiz (ou âncora) de uma cadeia completa ou o próximo link de uma cadeia incompleta que pode ou não ser a raiz/âncora .
Como pano de fundo, como você não indica o quanto entende de verificação baseada em certificado, ts -verifyconsiste basicamente em quatro partes:
verificar a assinatura no corpo do token verifica usando a chave pública no certificado do signatário (reivindicado) e algumas outras restrições impostas pelo RFC3161 são atendidas (deve haver apenas um SignerInfo e deve usar assinadoAttrs incluindo ESSCertId). Se o certificado do signatário está incluído na resposta do carimbo de data/hora é controlado por um sinalizador na solicitação RFC3161; se não estiver incluído, o verificador/confirmador deverá já tê-lo ou obtê-lo por outros meios.
construir uma cadeia (também chamada de caminho) que vincule o certificado do signatário reivindicado a pelo menos uma CA confiável, representada por um certificado de CA denominado certificado raiz ou âncora que é definido localmente como confiável, normalmente por estar presente em um armazenamento confiável. A resposta RFC3161poderiaincluir o(s) certificado(s) da cadeia, mas não é obrigatório; caso contrário, o verificador/confirmador deve já tê-los ou obtê-los por outros meios.
validar a cadeia verificando se a assinatura de cada certificado é verificada sob a chave pública do próximo certificado superior (ou seja, do pai), se cada certificado é válido (em vigor e não expirado) no momento da assinatura e vários outros campos em cada certificado são apropriado para seu uso na cadeia; veja os detalhes emRFC5280 seção 6. Validaçãodeveinclui a verificação de que cada certificado da cadeia não foi revogado (a partir do momento da assinatura), mas o OpenSSL não faz essa parte por padrão; existem várias opções para fazer diversas variantes de verificação de revogação, mas você não usou nenhuma delas.
por fim, verifique se o certificado (cadeia) é adequado para o propósito aqui, ou seja, carimbo de data/hora. Para outros casos de uso de certificados como SSL/TLS e S/MIME, geralmente precisamos verificar não apenas se o certificado foi emitido legitimamente sob a autoridade de uma CA confiável, mas também se foi emitidoparauma entidade específica (um site, ou servidor de e-mail, ou pessoa que foi identificada de forma confiável). No entanto, para carimbo de data / hora, geralmente não nos importamosqualA TSA emitiu o token, só quealgunsTSA válido fez, portanto, esta última verificação verifica apenas se ExtendedKeyUsage do certificado/cadeia inclui (o OID padronizado e, portanto, permite) timeStamping.
Tomados em conjunto (e apenas em conjunto), estes estabelecem que os dados que temos são, na verdade, um token de carimbo de data/hora emitido por uma TSA válida e não foram falsificados ou alterados, intencionalmente ou não, e, portanto, podem ser confiáveis.
Para linha de comando OpenSSL, a raiz/âncora deve estar no armazenamento confiável usado, que consiste no CAfile -CAfilee/ou -CApathCApath especificado e/ou padrão, se existirem, em ambos os casos no formato PEM; e (embora a página de manual não seja muito clara) qualquer outro(s) certificado(s) de cadeia que não esteja(m) na mensagem de resposta deve(m)qualquerestar no armazenamento confiável ou no arquivo fornecido como -untrusted(que deve ser um único arquivo, mas pode conter vários certificados no formato PEM). Por padrão, apenas um certificado raiz é (e historicamente apenas uma raiz era) aceito como uma âncora de cadeia/caminho, mas com a -partial_chainopção desde 1.0.2 uma âncora não raiz no armazenamento confiável é aceita.
O ts -reply -textdisplay não mostra o nível do CMS e, em particular, quais certificados são fornecidos nele. Você pode ver tudo, asn1parse -inform der [-i]mas deve decodificá-lo manualmente. Mais convenientemente, você pode extrair a parte CMS SignedData, também conhecida como token assinado, conformeminha resposta aquie, em seguida, examine os certificados da seguinte forma:
openssl ts -reply -in respfile -token_out -out tokenfile
openssl pkcs7 -inform der -in tokenfile -print_certs
# if desired/necessary, feed any or each of the PEM cert block(s)
# to openssl x509 -text -noout to get full details
Não tenho experiência com este TSA, mas com base no princípio de que o certificado e a cadeia de um TSA público bem conhecido devem ser registrados publicamente, o único certificado registrado com esse assunto conhecido por crt.sh (que também é administrado pela Comodo-agora -Sectigo) éhttps://crt.sh/?id=1437463789que tem um pai conhecidoSectigo RSA Time Stamping CA https://crt.sh/?id=1437089092cujo emissor é USERTrust RSA Certification Authority; que a CA tem quatro certificados (pais em potencial) listados emhttps://crt.sh/?caid=1167- um deles Microsoft codesigning, que normalmente seria usado apenas se o carimbo de data / hora for para uma assinatura de código Microsoft Authenticode, e os outros três são todos razoáveis para uso geral, embora o único chamado Comodo seja bastante recente (emitido há apenas 3 meses) . FWIW o AIA em id = 1437089092 aponta parahttp://crt.usertrust.com/USERTrustRSAAddTrustCA.crtque serve o certificado da raiz AddTrusthttps://crt.sh/?id=4860286que é o mais antigo (emitido em 2000 e expira em um ano).
Use o(s) certificado(s) na mensagem para determinar quais certificados adicionais de cadeia e âncora são necessários para a raiz ou âncora que você deseja usar e compare com o que é fornecido em seu -CAfileou em outro arquivo que você possa usar com -untrusted.