keytool和openssl证书指纹不匹配 [英] Mismatch in keytool and openssl certificate fingerprint

问题描述

我正尝试在META-INF/中为Android开发人员证书添加指纹，以用于研究目的.

I was trying to fingerprint android developer certificates, inside META-INF/, for research purposes.

我正在发现某些场景，其中来自keytool和openssl的输出将为同一证书提供不同的SHA1指纹:

I'm finding certain scenarios in which output from keytool and openssl would give me different SHA1 fingerprints for the same certificate:

使用键盘工具:

keytool -princert -file META-INF/CERT.RSA
...
    SHA1: 9D:17:FB:AB:67:BB:D0:7B:12:FE:E8:33:7D:66:F1:C4:2B:03:BD:F7
...

使用openssl:

openssl pkcs7 -inform DER -in META-INF/CERT.RSA -print_certs -out CERT.cert
openssl x509 -in CERT.cert -fingerprint -noout
     SHA1 Fingerprint=80:D5:CD:66:6E:44:75:62:A8:B3:7E:5D:AC:00:DE:1D:FF:6B:E6:CA

这是正常的吗?-keytool使用自己的方式来对指纹证书进行指纹识别，这与openssl-有所不同，我做错了什么，还是某个地方有错误?

Is this normal - keytool uses its own way to fingerprint certs, which differs from openssl- , am I doing something wrong, or is there a bug somewhere?

顺便说一句，我不是专家，所以随时提供任何建议，甚至是最基本的东西！

By the way, I'm no expert, so feel free to give any advice, even the the most basic stuff!

如果您需要一个示例，我可以为您提供发生这种情况的android应用的名称.

If you need an example of this, I can give you the name of an android app in which this happens.

谢谢.

推荐答案

不同的SHA1指纹是由代码签名证书的不同编码引起的.

The different SHA1 fingerprints are caused by different encodings of the code signing certificate.

第一个指纹(通过密钥工具)是根据证书字节计算出的，完全与PKCS#7文件META-INF/CERT.RSA中包含的证书字节相同.签名的长度(证书的长度，而不是代码的签名)在此处以两个字节编码，实际上一个字节就足够了.要看到这一点，我们必须看一下CERT.RSA的ASN.1转储.有几个程序可以做到这一点，但是我建议彼得·古特曼(Peter Gutmann)的 dumpasn1/GUIdumpASN .相关的部分是这样的:

The first fingerprint (by keytool) is calculated over the certificate bytes exactly as they are contained in the PKCS#7 file META-INF/CERT.RSA. The length of the signature (of the certificate, not the signature of the code) is encoded here in two bytes, where actually one byte would be enough. To see this we have to take a look at the ASN.1 dump of CERT.RSA. There are several programs that can do this, but I recommend Peter Gutmann's dumpasn1/GUIdumpASN. The relevant part is this:

    <06 09>
532   9:             OBJECT IDENTIFIER
       :               sha1WithRSAEncryption (1 2 840 113549 1 1 5)
    <05 00>
543   0:             NULL
       :             }
    <03 82 00 81>
545 129:           BIT STRING    
       :             65 26 30 0C 41 32 63 75    e&0.A2cu
       :             2F B7 DF 9A 96 37 72 1B    /....7r.

字节82 00 81是长格式.

根据杰出的编码规则DER ，""可能是最短的必须使用长度编码"，该编码本应为81 81.这意味着代码签名证书未完全进行DER编码.

According to the Distinguished Encoding Rules DER the "shortest possible length encoding must be used", which would have been 81 81. This means that the code signing certificate is not completely DER encoded.

当您使用openssl导出证书时，它将证书重新编码为有效的DER:

When you exported the certificate with openssl, it re-encoded the certificate to valid DER:

    <03 81 81>
489 129:   BIT STRING    
        :     65 26 30 0C 41 32 63 75    e&0.A2cu
        :     2F B7 DF 9A 96 37 72 1B    /....7r. 

因此，证书的哈希值(指纹)不同，因此已更改.

Therefore the hash value (fingerprint) of the certificate is different, it has changed.

keytool和openssl都没有做错任何事情. DER编码的要点在于，它始终生成与ASN.1结构完全相同的字节表示形式.

Neither keytool nor openssl did something wrong. The point of DER encoding is that it generates always exactly the same byte representation of ASN.1 structures.

导致此问题的软件是创建错误代码签名证书的工具.

The software that caused this issue is the tool the faulty code signing certificate was created with.

这篇关于keytool和openssl证书指纹不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！