For concreteness, let's take the concrete case of RSA. You generate your keys -- will consist of a public key -- two numbers (N, e) and a private key (N, d) so that if you use
c = m^e mod N to encrypt an RSA message you can use
m = c^d mod N to decrypt it. (In reality its not quite so simple, you have to worry about hybrid encryption, padding, constant-time modular exponentiation).
Certificates will contain the public key, plus data describing the organization, all of which is generally cryptographically signed -- typically by another trusted entity, except for self-signed certificates which are signed by their own public-key. To sign someone's certificate (which I will call
cert) you need the private key
S = Hash(cert)^d mod N. However, to verify that a signature is correct you only need a public key, by checking that
S^e mod N is the same as the hash of the original
So to answer your questions:
Certificates are not the public key, but contain (1) the public key along with (2) other identifying information (who the organization is, what resources the certificate should be used for), and (3) a signature from some other trusted organization.
If you want to validate the certificate for say
https://crypto.stackexchange.com, your browser (or OS) needs to ultimately follow a chain of trust to a certificate it knows and trusts. That is the certificate served by stackexchange is valid for
*.stackexchange.com is validated to belong to
Stack Exchange, Inc. operated out of New York, NY. It was signed by
DigiCert High Assurance CA-3 (who presumably validated the identity of Stack Exchange). The DigiCert High Assurance CA-3 intermediate Certificate Authority was itself signed by
DigiCert High Assurance EV Root CA. The public certificate for
DigiCert High Assurance EV Root CA is self-signed and your OS or web browser needs to have it to be able to trust it (e.g., for an OS may be stored:
/etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem or for a web browser
I think you had the gist of it. You create one CA with a CA certificate (acting as a public key + more data) that you share widely, and a private key kept secret only used to sign other certificates. When one of your machines (call it M) needs a certificate - private-key pair (e.g., to do SSL), then M creates their own private key and a certificate signing request (CSR) -- basically an unsigned certificate (technically it is self-signed - to ensure it wasn't tampered prior to being signed by the CA). The CSR is securely sent to the computer with the CA's private key, which signs the CSR to create a signed-certificate which is sent back to M. Now M can create use the certificate plus its own private key to setup SSL connections.