The "Standard Model" of Certificate generation:
On the server machine: Generate CSR operation
+-------------+ +-----------------------------+ | Private Key | | Certificate Signing Request | +------+------+ | | v | +------------+ | | | Public Key | | | +------------+ | | | | "Distinguished Name" | | | Note: hash is signed | +------------+ | by private key above | | Hash | | | +------------+ | +--------------+--------------+ | | Sent to CA for signing v +-----------------------------+ CA can use public key | Certificate | from CSR to check | | signature on hash to | +------------+ | prevent alteration of | | Public Key | | CSR by adversary | +------------+ | | | | "Issuer Distinguished Name" | | | | "Subject DistinguishedName" | | | Note: hash is signed | +------------+ | by private key of root | | Hash | | | +------------+ | +--------------+--------------+ | | Returned to server v
In secure site operation:
Server presents certificate to client
Client uses public key of root (obtained from preconfigured root certificate) to check hash to ensure certificate has not been forged.
Client rolls a random number and encrypts it with the public key from the server certificate, then returns it to the server.
Server decrypts this with server private key and both sides use it as a symmetric key for conventional (e.g., DES) cryptography.
Eavesdropper does not have access to private key so cannot decrypt. Man-in-the-middle attacker does not have access to private key so cannot decrypt.
-- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
