8

When creating a signed certificate I get the lines inside the certificate that identify the keys used:

  X509v3 extensions:
     X509v3 Subject Key Identifier: 
         D8:D7:3F:99:CC:D7:20:AF:62:31:E2:EA:2C:8C:28:8C:B8:2F:0B:96
     X509v3 Authority Key Identifier: 
         keyid:D8:D7:3F:99:CC:D7:20:AF:62:31:E2:EA:2C:8C:28:8C:B8:2F:0B:96

Question: Given the CA key and the server key, is there a openssl command sequence with which I can generate the Subject Key Identifier and the Authority Key Identifier by hand?

3
  • Are you asking whether you can programatically derive the same Key Identifier values given the appropriate public keys? Or are you asking if you can use openssl to arbitrarily alter the Subject and Authority Key Identifier fields of a certificate?
    – gowenfawr
    Commented Jul 1, 2016 at 17:20
  • I would like to programatically (through openssl command calls) recreate the SKI and AKI from a key. Actually I found the answer for SKI here now: certificateerror.blogspot.se/2011/02/…. Does anyone know how it is done for AKI? The certificate is selfsigned, so the above two Identifiers should reference the same key, but they are different... Commented Jul 1, 2016 at 18:10
  • ehem,,,they the same. solved. Commented Jul 1, 2016 at 20:13

2 Answers 2

16

From http://certificateerror.blogspot.se/2011/02/how-to-validate-subject-key-identifier.html.

Extract SKI from cert:

#!/bin/bash                                                                                                                                                             
openssl x509  -noout -in $1 -pubkey  | openssl asn1parse  -strparse 19 -noout -out - | openssl dgst -c -sha1

Extract SKI from key:

#!/bin/bash                                                                                                                                                             
openssl rsa -in $1  -pubout | openssl asn1parse -strparse 19 -noout -out - | openssl dgst -c -sha1
  1. openssl x509 -pubout extracts a public key from an x509 document.
  2. openssl asn1parse decodes an ASN.1 object and performs any chosen operations on it.
  3. -strparse 19 skips the first 19 bytes, a magic number. Typically the public keys is in PKCS#1 format. So for an RSA public key of 2048 bits it starts with 4 bytes of SEQUENCE, 2 bytes of SEQUENCE, 11 bytes to store the OID 1.2.840.113549.1.1.1 meaning rsaEncryption, 2 bytes for a NULL terminator on the sequence. That is 19 bytes, which starts the BIT STRING data structure and continues to the end of the data.
  4. openssl dgst produces the digest of the input using the chosen output format and digest algorithm
3
  • Could you click "Accept" if this worked for you? (That way it will no longer be listed in the "Unanswered" section.) Commented Dec 29, 2016 at 12:54
  • The first line does not work. The output if -pubkey is PEM encoded, so asn1parse needs to have -inform pem to work. Unfortunately, -outform does not work for x509 to affect the pubkey. For ECDSA keys, I don't think that the asnparse step is needed.
    – mcr
    Commented Oct 22, 2019 at 18:02
  • 1
    @mcr: that's incorrect; asn1parse defaults to -inform pem -- although unlike other OpenSSL functions it doesn't check the BEGIN/END lines, ignoring them and processing any base64. But: -strparse 19 is correct only for an RSA key of at least 1800 bits (and less than about 524k bits, IINM, which shouldn't be an issue). DSA and ECDSA require different offsets, which vary depending on the group/curve used. Note -strparse for ECDSA without -noout will display an error, because X9.62 point format is not ASN.1, but it still extracts correct data to -out file Commented Oct 23, 2019 at 6:26
0

Extract from SKI from cert:

#!/bin/bash
openssl x509  -noout -in $1 -pubkey -outform der | openssl asn1parse -inform pem -noout -out tmp.pub.der
openssl dgst -c -sha1 tmp.pub.der

Please also be aware that SHA-1 is not used as often to form the SubjectKeyIdentifier. SHA-256 is used, which is why it is better to have the certificate generator generate this.

1
  • That's wrong or at least unconventional; rfc5280 says you should hash only the 'bit string' (algorithm-specific) part, which the accepted answer selects using -strparse, NOT all of SubjectPublicKeyInfo as you do. And I've not seen anyone change away from SHA1 for SKI/AKI. Can you give some examples? Or are you maybe thinking of cert fingerprints? Those have (mostly) moved from MD5 to SHA1 and now SHA256. Commented Oct 23, 2019 at 6:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .