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.
John <---- SIGN_LTsec(Wpub) ---- Webserver
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.