5

There is quite some information on the web on how to extract the base 64 encoding of the SHA-256 fingerprint (which is needed for the Public Key Pinning header) for RSA certificates (e.g. by Mozilla).

However, I'm not sure how to get the same information for an ECC certificate. Replacing rsa by ec seems a decent idea, however openssl ec -in my-key-file.key -outform der -pubout does not only print the actual content of the key, but also

read EC key
writing EC key

beforehand. I guess this boilerplate output is included in the stuff that's SHA-256-hashed, thus invalidating the whole procedure. Is there any way to circumvent this?

4
  • 2
    openssl rsa similarly says writing RSA key (though not read). In both cases these are written on standard error (aka file descriptor 2 on Unix) and thus not included in the data piped to the hash and base64 operations. Or in 1.0.0+ (since 2010) you can use openssl pkey -in privkey [-inform pem|der] -pubout -outform der for RSA and EC (and DSA too but practically no one uses that) and it doesn't output any extraneous messages. Jun 22, 2015 at 14:26
  • Thank you for that insight! Do you know whether the same is true for OpenSSL on Windows?
    – TheWolf
    Jun 23, 2015 at 6:27
  • 1
    It certainly is for the ShiningLight build (which I use and is actually the one I checked when posting the above; it uses Microsoft Visual C) and it should be for any implementation of standard C on Windows including at least MinGW and CygWin. If you have some really old 1980s C running in MSDOS emulation (not on 64bit!) it might get stdout/stderr wrong, but you probably can't get OpenSSL compiled such an old implementation in the first place. Jun 23, 2015 at 10:45
  • You might try openssl x509 -noout -text -fingerprint -sha256 -in /path/to/cert, to get the fingerprint for the certificate (as RFC 7469 talks of the subject public key info for certificates).
    – Castaglia
    Feb 17, 2016 at 23:30

1 Answer 1

1

There's extra status output but it goes to the StdErr stream. So it goes to console (i.e. screen display) and does NOT go down into the pipe. Regular output is part of the "StdOut" stream. That stream goes into the pipe. This is valid for *nix and Windows, too.

Here's an example.

Generate a key:

C:\>openssl ecparam -name secp256k1 -genkey -noout -out secp256k1-key.pem

If you redirect nothing then both streams end up on the screen:

C:\>openssl ec -in secp256k1-key.pem -noout -text
read EC key
Private-Key: (256 bit)
priv:
    00:d6:09:84:21:77:32:86:bb:5d:c9:da:30:ce:dc:
    98:28:f1:f2:f2:2e:2a:9a:91:28:c3:88:b2:bb:80:
    51:24:39
pub:
    04:e3:4b:2c:96:44:08:18:9f:37:bb:b5:8e:44:52:
    69:f4:4b:7f:a7:2a:61:9e:5a:39:1a:07:7a:d6:27:
    e8:8f:83:36:fa:a6:72:e9:f5:7c:41:53:0c:b6:16:
    ab:24:7a:0d:82:2c:b9:cc:2d:2b:08:38:83:e2:ac:
    4e:d7:9a:09:91
ASN1 OID: secp256k1

If you throw away stream "1", which is StdOut, then what you are left with is stream "2", which is just StdErr:

C:\>openssl ec -in secp256k1-key.pem -noout -text 1>NUL
read EC key

You can throw away stream "2" as well:

C:\>openssl ec -in secp256k1-key.pem -noout -text 2>NUL
Private-Key: (256 bit)
priv:
    00:d6:09:84:21:77:32:86:bb:5d:c9:da:30:ce:dc:
    98:28:f1:f2:f2:2e:2a:9a:91:28:c3:88:b2:bb:80:
    51:24:39
pub:
    04:e3:4b:2c:96:44:08:18:9f:37:bb:b5:8e:44:52:
    69:f4:4b:7f:a7:2a:61:9e:5a:39:1a:07:7a:d6:27:
    e8:8f:83:36:fa:a6:72:e9:f5:7c:41:53:0c:b6:16:
    ab:24:7a:0d:82:2c:b9:cc:2d:2b:08:38:83:e2:ac:
    4e:d7:9a:09:91
ASN1 OID: secp256k1

As for the "Why?": I don't know. I think that's just one of the many quirks of the OpenSSL command line utilities.

You must log in to answer this question.

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