Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
It's hard to comment without a sample of the output of .NET's X509Certificate class.. –  ansur Oct 1 '12 at 12:34
1  
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 –  Despertar Oct 1 '12 at 17:18

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
1  
welcome to Information Security. Answers are only supposed to be used to answer the question, not to start a debate or respond to other comments or answers. Please see the FAQ, and How to Answer. Thanks! –  AviD Oct 2 '12 at 12:17
    
How was I starting a debate? Despertar does have misconceptions. Bruno corrected some of them. I attempted to correct some as well. Despertar questioned the relevancy of my question and I explained why it was relevant. Well I suppose "questioned" isn't the right word. He was more like "this is not relevant" as a matter of fact. Which is pretty consistent with his whole posting style. He's like "I've found [this]" and "What is odd is [that]". The only time he ever asks a question is his first post and all subsequent posts are more like "this is how it is" even though that isn't how it is. –  ansur Oct 2 '12 at 14:18
    
@ansur Our format isn't that of a forum. Your "answer" doesn't really perform the job of explaining how a certificate signer is verified. –  Jeff Ferland Oct 2 '12 at 18:22
    
Neither does Bruno's "answer". He simply corrects a misconception as I do. I suppose technically he did a comment but (1) my post was too long for a comment and (2) I don't have a ton of points. I don't think I even had the ability to do comments until after I did my first post idk. –  ansur Oct 3 '12 at 20:19

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 DER binary format, you can decode it into plain text 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.

share|improve this answer
1  
"encrypting" the hash with the private key isn't quite right. See: security.stackexchange.com/a/20925/2435 –  Bruno Oct 2 '12 at 1:33
    
@Bruno Yeah I had just read that one as well. Turns out it uses a digital signature algorithm rather than encryption. I'll update that part, thanks. –  Despertar Oct 2 '12 at 1:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.