Wie kann man wissen, welche X509-Zertifikat ein anderes Zertifikat (Java)

Question

Es gibt drei Zertifikate in meinem Beispiel Signed, annehmen, dass sie eine Kette bilden, aber ich weiß noch nicht von ihnen, die unterzeichnet, die:

X509Certificate c1 = .... 
X509Certificate c2 = .... 
X509Certificate c2 = .... 

würde ich möchte wissen, welches Zertifikat für das Signieren des anderen Zertifikats verantwortlich ist.

Der Plan war, die "AuthorityKeyIdentifier" zu bekommen und mit der "SubjectKeyIdentifier" zu vergleichen.

import org.bouncycastle.asn1. DEROctetString; 

private static String decodeKey(byte[] e) { 
    DEROctetString octet = new DEROctetString(e); 
    return octet.toString(); 
} 

String subjectKeyId = decodeKey(c.getExtensionValue("2.5.29.14")); 
String authorityKeyId = decodeKey(c.getExtensionValue("2.5.29.35")); 

Im die Zertifikate die folgenden für das Erhalten (in der Reihenfolge der Kette): subject/Behörde Schlüssel-ID Paar

Werte der SubjectKeyIdentifier und AuthorityKeyIdentifier nach der Decodierung:

Zertifikat 1: (end die Kette)

#0416041482b7384a93aa9b10ef80bbd954e2f10ffb809cde 
#04183016801482b7384a93aa9b10ef80bbd954e2f10ffb809cde 

Zertifikat 2: 1

durch Zertifikat signiert

#04160414ab8059c365836d1d7d13bd19c3ec1a8f0d476aa3 
#04183016801482b7384a93aa9b10ef80bbd954e2f10ffb809cde 

Zertifikat 3: Signed by-Zertifikat 2

(no SubjectKeyIdentifier - null bytes) 
#041830168014ab8059c365836d1d7d13bd19c3ec1a8f0d476aa3 

Formatiert und Aligned für eine einfache Lesung (Das Gleiche gilt als über)

------------------------------------------------------------------------------ 
     01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
------------------------------------------------------------------------------ 
Certificate 1 
#04 16 04 14  82 b7 38 4a 93 aa 9b 10 ef 80 bb d9 54 e2 f1 0f fb 80 9c de 
#04 18 30 16 80 14 82 b7 38 4a 93 aa 9b 10 ef 80 bb d9 54 e2 f1 0f fb 80 9c de 

Certificate 2 
#04 16 04 14  ab 80 59 c3 65 83 6d 1d 7d 13 bd 19 c3 ec 1a 8f 0d 47 6a a3 
#04 18 30 16 80 14 82 b7 38 4a 93 aa 9b 10 ef 80 bb d9 54 e2 f1 0f fb 80 9c de 

Certificate 3 
=== == == == == == == == == == == NO DATA == == == == == == == == == == == == 
#04 18 30 16 80 14 ab 80 59 c3 65 83 6d 1d 7d 13 bd 19 c3 ec 1a 8f 0d 47 6a a3 

Ich erwartete AuthorityKeyIdentifier des c3 als äquivalent zu c2's SubjectKeyIdentifier. das scheint hier nicht der Fall zu sein.

EDIT: einige Teile des Ergebnisses scheinen zu entsprechen, ich habe eine Idee auf dem "SubjectKeyIdentifier" - es beginnt immer mit "# 04" gefolgt von der Länge des Inhalts (in hex). Ich habe jetzt eine gewisse Idee, wie man den "SubjectKeyIdentifier" entschlüsseln kann, aber der "AuthorityKeyIdentifier" ist für mich immer noch ein großes Rätsel.

relevant SO post

Habe ich etwas falsch gemacht mit der Decodierung? Warum stimmt der AuthorityKeyIdentifier nicht korrekt mit dem SubjectKeyIdentifier des Zertifikats überein, das ihn signiert hat?

Answer 1

Wenn Sie einen Blick auf die ASN.1-Definition von SKI und AKI in RFC5280 nehmen (die Links in Ihrer Frage) der Unterschied deutlich:

SubjectKeyIdentifier ::= KeyIdentifier 

AuthorityKeyIdentifier ::= SEQUENCE { 
    keyIdentifier    [0] KeyIdentifier   OPTIONAL, 
    authorityCertIssuer  [1] GeneralNames   OPTIONAL, 
    authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 

KeyIdentifier ::= OCTET STRING 

Also, die AKI nicht ein OCTET STRING , aber eine Folge von drei optionalen Elementen. Eines dieser Elemente ist der Oktettstring, der mit einem SKI verglichen werden kann.

Die Distinguished Encoding Rules (DER) ermitteln die Byte-Darstellung dieser ASN.1-Strukturen. Der einzelne Bytes einer AKI Erweiterung hat die folgende Bedeutung (siehe A Layman's Guide to a Subset of ASN.1, BER, and DER):

04 18 30 16 80 14 82 b7 38 4a 93 aa 9b 10 ef 80 bb d9 54 e2 f1 0f fb 80 9c de 

04 OCTET STRING 
18 LENGTH 
30 SEQUENCE 
16 LENGTH 
80 CONTEXT-SPECIFIC PRIMITIVE TAG 0 
14 LENGTH 
.. DATA 

Die ersten zwei Bytes (04 18) einen Teil der Verlängerungsstruktur (wie in der verwandten Frage Why doesn't my key identifier match? erklärt wird), ist die tatsächliche AKI Erweiterungsinhalt beginnt bei "30 16".

Ihr Java-Code für die AKI Decodierung sollte wie folgt aussehen (mit Hüpfburg):

byte[] extensionValue = cert.getExtensionValue("2.5.29.35"); 
byte[] octets = DEROctetString.getInstance(extensionValue).getOctets(); 
AuthorityKeyIdentifier authorityKeyIdentifier = AuthorityKeyIdentifier.getInstance(octets); 
byte[] keyIdentifier = authorityKeyIdentifier.getKeyIdentifier(); 
String keyIdentifierHex = new String(Hex.encode(keyIdentifier)); 

Und für SKI Decodierung:

extensionValue = cert.getExtensionValue("2.5.29.14"); 
octets = DEROctetString.getInstance(extensionValue).getOctets(); 
SubjectKeyIdentifier subjectKeyIdentifier = SubjectKeyIdentifier.getInstance(octets); 
keyIdentifier = subjectKeyIdentifier.getKeyIdentifier(); 
keyIdentifierHex = new String(Hex.encode(keyIdentifier)); 

Auch beide Erweiterungen sind optional. Wenn Ihr Code mit beliebigen Zertifikaten arbeiten soll, ist ein Fallback-Mechanismus notwendig (wie zum Beispiel die Überprüfung der Signaturen).

Answer 2

Wenn Sie nach einer wirklich schnellen Überprüfung suchen, öffnen Sie einfach das Zertifikat in Windows und suchen Sie nach einem Tab namens "Certification Path". Darüber hinaus können Sie die Zertifikatskette, falls zutreffend, problemlos durchlaufen. (Ich würde ein Bild posten, aber anscheinend noch nicht genug Ansehen.)