How is an X509 certificate signer verified?

Question

Lets say I create a self-signed certificate A and use it to issue certificate B. I put certificate A in my trusted root authorities so that all certificates signed by it are accepted. My question is,

When I then use a service protected by cert B, how does my computer know it was actually signed by cert A? Is the parent certificate somehow embedded into it's child?

Answer 1

In a X.509 certificate, the name of the issuer (in your example, A's name) is also included (as issuerDN). Also, a certificate can contain an extension which points to a place where the issuer's certificate can be downloaded (the "Authority Information Access", section 4.2.2.1 of RFC 5280); note that since all certificates are signed entities which are accepted and use only after having verified these signatures, they can be downloaded and transported with little care. Finally, it is customary, in protocols where a party can show a certificate, to actually show a list of certificates containing needed intermediate CA certificates. This is what happens, for instance, in an SSL Certificate message.

All this gives a lot of ways for a computer to do certification path building, i.e. reconstructing chains of certificate on which validation (including verifying cryptographic signatures) seems relevant.

Answer 2

When the CA issues the certificate, they sign it using their private key. Only the CA's public key can verify that the signature is authentic and the certificate has not been tampered with.

---

What is odd is that the signature property seems to be missing in a lot of instances (.NET's X509Certificate class and when viewing a certificate in Windows). I've found that even though it is not always displayed, it is still inside the certificate. Given a certificate in say DER binary format, you can convert it back to its original text form which DOES show the signer's signature.

openssl x509 -text -noout -inform DER -in certFile.der

---

Signature Algorithm: sha1WithRSAEncryption
    30:d9:40:ac:d8:0d:46:81:68:14:8a:c6:a7:29:96:4e:b4:58:
    7b:e6:12:3f:45:4f:c6:9b:18:aa:f2:99:23:ee:48:df:5f:c0:
    a3:c7:e4:ba:3a:bc:6f:58:57:fe:a8:a7:23:d0:d1:9a:47:a6:
    42:1a:d8:20:e8:f1:ec:76:43:47:0b:75:d6:a1:d2:71:2b:f7:
    19:96:e3:48:57:e2:36:0f:0c:25:5d:7f:f8:26:50:c2:5e:80:
    8e:17:ac:37:ad:f1:e3:3c:6f:a3:20:a6:16:93:df:2b:04:9c:
    22:d3:01:33:f9:4c:3b:f8:a8:39:f1:6c:41:74:de:ba:96:6a:
    0b:f1:e6:f0:7b:d8:1f:42:ec:b5:73:d1:94:1b:01:4a:4c:13:
    ca:5e:2b:af:fd:2c:eb:43:d3:fc:2f:ea:5a:8d:db:a9:6a:f6:
    b6:9b:58:e1:b7:94:7f:14:6d:11:8b:2c:b7:4e:f3:82:ad:c4:
    92:04:c4:97:a3:7a:52:e5:a0:b1:1b:8f:47:bb:43:a3:2c:1a:
    fb:31:d9:51:7c:23:7b:57:8e:73:46:81:c4:25:f3:48:c5:a1:
    8f:0d:3d:f2:e1:4b:fd:7f:49:b9:f9:b1:2a:c2:22:9e:8a:85:
    61:bd:b7:18:8e:56:33:a4:6e:d2:7d:db:2e:37:d0:fb:9a:35:
    87:c8:2a:69

---

From http://en.wikipedia.org/wiki/X.509

To validate this certificate, one needs a second certificate that matches the Issuer (Thawte Server CA) of the first certificate. First, one verifies that the second certificate is of a CA kind; that is, that it can be used to issue other certificates. This is done by inspecting a value of the CA attribute in the X509v3 extension section. Then the RSA public key from the CA certificate is used to decode the signature on the first certificate to obtain a MD5 hash, which must match an actual MD5 hash computed over the rest of the certificate.

Answer 3

I can't respond to comments so...

This question is language-agnostic. When people say 'ssl certificate' or just 'certificate' they are usually referring to an x509 certificate, en.wikipedia.org/wiki/X.509"

Very well. In that case, then, let me clear up a few misconceptions you seem to have.

From your original post:

I've found that given a certificate in any format (say DER), you can convert it back to its original text form which DOES contain the signer's signature.

The output of openssl asn1parse isn't the "original text" by any means. It's just a human readable version of the DER (which itself is a base64 decoded PEM).

An X.509 certificate must contain the "signers signature". If it didn't it wouldn't be an X.509 certificate. Whether or not .NET's X509Certificate class outputs the "signers signature" is another matter. And in lieu of knowing what it does output I can't really comment on that.

What is odd is that the signature property seems to be missing in a lot of instances (.NET's X509Certificate class and when viewing a certificate in Windows).

To recap... the "signature property" is always present. The human readable version of the X.509 certificate .NET's X509Certificate class gives you may not include it but that does not mean the DER doesn't have it. It does.