DHE Verification

(Certificates are not "encrypted", they are signed. Signatures are not the same as encryption. Describing signatures as "encryption with the private key" is a flawed analogy which does not work with non-RSA signature algorithms, and does not work well with RSA either, and it only leads to confusion. Let's use the proper terminology.)

In DHE, the SSL server has a certificate, issued (signed) by a CA, and containing a public key which is apt for signatures (e.g. RSA, DSA, ECDSA...). The server sends that certificate to the client, along with the newly-generated DH parameters, that the server signs with that key.

In static DH, the client verifies that the DH public key is part of a certificate signed by the CA, and bearing the intended server name. With DHE, the client verifies that the DH public key is signed relatively to a signature public key, which is contained in a certificate signed by the CA and bearing the intended server name. DHE implies one more level of signing, but it still ultimately links to the CA system.

(In practice, static DH is exceedingly rare; everybody uses RSA for certificates.)

It may be more reasonable to refer to ElGamal at this point, which you can think of as "delayed Diffie-Hellman" an does what you describe as "static Diffie-Hellman". The way it works is basically as follows

You generate secret/public long-term keypair LTsec and LTpub 

You send LTpub to a CA, which may contact you by telephone or anything else to verify that you are really you. Once the verification is done they sign LTpub. That means you get a signed certificate which consists of your public key and the CA's signature:

(new) LTpub = (LTpub, CAsig of LTpub) 

You can then use that to authenticate yourself or your server or whatever you want. You may for example let your webserver at www.example.com authenticate with that certificate. When John connects to that server and wants to use DH Key Agreement that happens (simplified):

John generates a new ephemeral DH keypair (Jpub, Jsec) and sends the public part to the webserver

 John ----- Jpub -----> Webserver 

The webserver generates a new ephmeral DH keypair (Wsec, Wpub) and sends the public part to John. It also signs Wpub with LTsec from above.

 Wpub John <---- SIGN_LTsec(Wpub) ---- Webserver LTpub 

Now John can now do certain things:

• John can now verify that Wpub was generated from someone who possesses LTsec (important!).
• John can also verify that the one who possesses LTsec is the one who generated LTpub.
• John can also verify that LTpub was verified by a CA.
• John can now assume that a CA once verified the information in LTpub by a telephone call (or whatever) and that the issuer is who he proposes to be (here: www.example.com)
• Finally John can resonably assume that he shares a key (Wpub^Jsec) with www.example.com

Of course this is only a very basic overview of the trust relationship and technical details.

After all, take a closer look at ElGamal for more technical information.