How are ECDSA signatures computed for X509 Certificates?

Question

I am trying to verify a certificate signature on my own. To do this, I created a self-signed certificate using OpenSSL with the two following command lines:

openssl ecparam -name secp256k1 -genkey -param_enc explicit -out private-key.pem

openssl req -new -x509 -key private-key.pem -out server.pem -days 730

You can take a look at my certificate here.

I can clearly distinguish the public key and the signature which respectively are:

public key

93 99 FD 9F 7F 04 48 AF 51 2C 6D 2D 69 04 B9 1F 88 A9 C2 64 31 8E 68 70 5B 55 C8 63 C2 C3 AC A4 17 BD 89 1A 5E 8E 08 C4 B7 92 AD AF 51 28 D3 AC BC CE 73 FA 5D D2 FE A7 EB 53 C7 6E 1A 00 84 2C

signature

32 BA FB EB A8 E9 BB 4B 2D 2B 19 12 65 11 EC BB F5 46 5E B5 59 3A 9D 42 F2 62 74 BA A0 E7 73 03 E1 4C CE 67 2B 7D 3B BA 75 E9 8B 95 95 57 E7 17 B7 C1 99 4B 71 96 74 89 67 5F DC B1 0C 71 3B 5F

My problem is that I don't understand what is the input of the signature algorithm (ECDSA with SHA256)?

I tried to verify the signature by performing ECC computations on a hash (SHA256) of all the data before the signature TLV (i.e. all except 03 48 00 30 45 02 20 32 BA FB EB A8 E9 BB 4B 2D 2B 19 12 65 11 EC BB F5 46 5E B5 59 3A 9D 42 F2 62 74 BA A0 E7 73 03 02 21 00 E1 4C CE 67 2B 7D 3B BA 75 E9 8B 95 95 57 E7 17 B7 C1 99 4B 71 96 74 89 67 5F DC B1 0C 71 3B 5F) but it seems that the signature is not valid with this input.

Answer 1

The signature is computed over the tbsCertificate (To-Be-Signed) data.

https://www.rfc-editor.org/rfc/rfc5280#section-4.1:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

https://www.rfc-editor.org/rfc/rfc5280#section-4.1.1.3 says:

The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signature field. The details of this process are specified for each of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

By generating this signature, a CA certifies the validity of the information in the tbsCertificate field. In particular, the CA certifies the binding between the public key material and the subject of the certificate.

So, the trivial version of what you got wrong is that you also need to exclude the leading 30 82 03 02. And you didn't trim enough off of the end. Namely, the 30 0A 06 ... part (the signature algorithm identifier).

But, using that already shown ASN/DER parsing, you see that the root SEQUENCE contains three children. The signature is over the first child only.