Skip to main content
added 359 characters in body
Source Link
chirond
  • 105
  • 1
  • 6

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.

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.

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.

Source Link
chirond
  • 105
  • 1
  • 6

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.