0
$\begingroup$

I have some understanding of how PKI works, similar to this: - https://knowledge.digicert.com/solution/SO16297.html - https://security.stackexchange.com/questions/59566/ssl-certificate-chain-verification - https://security.stackexchange.com/questions/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity

What isn't obvious to me is how the public key at the end of the chain, or the identity certificate is used. Previously RSA may have been used for encryption, or as the key exchange for a symmetric cipher key, however ECDHE appears to be the modern primitive for key exchange.

My guess is the certificate is also signed by itself, along with the intermediates and roots in the chain. This would make sense to me since in my mind anyone would be able to use the cert in various ways, however if signed with the private key of the identity it's an extra check. Other wise I would see the identity private key as being pretty useless.

Most explanations are very simple with how a chain is evaluated and I'd like some detail.

So my question - is an identity certificate also signed by itself? Does my logic above stand up?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
1
$\begingroup$

A certificate is a binding between a public/private keypair and an identity. In essence, it's a note saying:

The public key [here] is owned by Alice,
- Your friendly neighborhood CA.

Now, if Alice passed you her certificate in a protocol, then (if you trust the friendly neighborhood CA) you know Alice's public key.

Now, your question is "what then?". Obviously, for Bob to know that he is talking to Alice, what she needs to do is do something with her private key to show that she knows it (and hence, as per the certificate, Bob knows that he really is talking to Alice).

For SSL (and earlier versions of TLS), her public key would be an encryption key; Bob would pick a value (the "premaster secret") and encrypt it with Alice's public key (which he gets from the certificate); if the other side can decrypt it, she must have the private key (and hence must be Alice).

Now, for later versions of TLS, it works differently. The public key within the certificate is actually a signature key. Alice and Bob use ECDH (or DH) to select keys; and then Alice signs the transcript of the exchange, and sends that to Bob. Bob has Alice's public key (again, from the certificate), and he knows the transcript in his side; he validates the signature; if that succeeds, he knows the other side is Alice (and also that someone in the middle hasn't tweaked anything; if they did, the signature verification would fail).

Also, to address the question you actually raised:

So my question - is an identity certificate also signed by itself?

No, it's not. There really wouldn't be much point to it; such a signature wouldn't stop any particular attack.

Improve this answer
$\endgroup$
5
  • $\begingroup$ This particular line is helpful: "Alice and Bob use ECDH (or DH) to select keys; and then Alice signs the transcript of the exchange". That's the info I'm looking for. $\endgroup$
    – chirond
    Commented Aug 31, 2018 at 22:58
  • $\begingroup$ @chirond: if the answer way helpful, then please upvote it (and maybe even accept it if you think it is the answer to your question) $\endgroup$
    – poncho
    Commented Aug 31, 2018 at 22:59
  • $\begingroup$ Done. As a side note, do you know of any resources to understand details such as this, and depth in PKI cert validations? $\endgroup$
    – chirond
    Commented Aug 31, 2018 at 23:08
  • $\begingroup$ Nits: SSL3 and all TLS versions support DHE. ECDHE works on all TLS (4492 normatively applies to both 2246 and 4346, and is adopted by 5346) and can even work on SSL3 with the extensions (10 and 11) defaulted; due to timing many implementations implemented ECC with 1.1 or sometimes 1.2, but e.g. OpenSSL implemented ECC from draft on TLS1.0 and SSL3 even before 2006, but TLS1.1 and 1.2 not until 2012. For both through 1.2, server signs only ServerKX body plus nonces; client signs full transcript, but ony if client-auth is used which is rare; 1.3 now does transcript both sides. $\endgroup$
    – dave_thompson_085
    Commented Sep 1, 2018 at 6:48
  • $\begingroup$ ... But even though DHE was long available and ECDHE may have been, very few people (at least on the public net) used them until Snowden made everbody, including managers and other people with control of money, aware of the benefits of PFS. $\endgroup$
    – dave_thompson_085
    Commented Sep 1, 2018 at 6:54
0
$\begingroup$

I may have found an answer here: https://devcentral.f5.com/questions/difference-between-root-cert-intermediate-cert-and-ssl-cert

One more thing one the public key of your server certificate. There is the same mathematical relationship as described above between the public key and private key of your server certificate.

It will be used during the SSL handshake. The client encrypts some key material servers public key (retrieved by the client out of the server certificate) and sends it to the server. It can be decrypted by the server using the private key. If the server does not have the matching private key it cannot decode the key material and the handshake brakes.

But the above may be referring to using RSA for symmetric key transference, which like I posted earlier is generally done by ECDHE these days.

I imagine you'd just be able to take the certificate and use it to spoof a site if you successfully hijack DNS without any validation of the identity certificates public key. Surely it's validated in some way.

Improve this answer
$\endgroup$
1
  • $\begingroup$ To spoof a site (or impersonate a cert holder in other applications either) you need the cert and the private key. For SSL/TLS using older plain-RSA key exchange you need the private key to decrypt the premaster (and otherwise you can't do the required Finished message); for DHE or ECDHE you need the private key to sign (and otherwise the client aborts). The entire concept of, and all of the security in, public-key cryptography depends totally on keeping the private key private while being able to make the public key public. $\endgroup$
    – dave_thompson_085
    Commented Sep 1, 2018 at 7:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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