1. A Certificate Authority issues a digital certificate (*1) for a fee. It is associated with a particular URL (e.g. forgivebank.com). The certificate has an expiration date.
   ===> How do we know the CA issued the certificate? It is signed using the private key of the CA.
2. Along with the certificate, which contains a public key, the URL and much other information, the purchaser receives a private key.
3. When a customer goes to forgivebank.com, part of the TLS (https) setup includes sending the certificate to the customer browser.
   ===> What does the browser validate?
   • URL in the certificate matches the URL. Otherwise the browser "complains".
   • The browser has the public key of the CA which it is claimed issued the certificate. The browser verifies - the only party who could have provided the valid digital signature is the issuing CA using its private key. (*2)
   • That the expiration date on the certificate is not expired. (*3)
4. The browser extracts the public key from the certificate and uses it in a TLS exchange with the forgivebank.com server to generate and exchange AES keys to be used during the session.
5. There is ongoing work to make the certificate system safer and more secure.

Notes:

1. There are several levels of certificate. The minimal is domain verification which means the CA has verified that the party requesting the certificate really does control the URL. This can be done with an automated system. The next level is Organization Validated Certificate. For this, the organization is authenticated by real agents against various databases. Browsers make little distinction between DV and OV certificates. The highest level, used by nearly all high value web sites, is an Extended Validation Certificate. It has extra information and has been more carefully vetted. The browser may display the lock differently. There is a lot of current debate on how or if the browser should make a distinction. Chrome has changed what it does multiple times in the last year.
2. Effectively, the browser vendors control which CAs are "official". There is nothing like an ICANN that controls who is a CA. There have been instances in which a CA made mistakes, violated security standards, or lost control of their private key and the browsers have simply removed their public key from the list. This is a death sentence to a CA because browser users will not be able to access web sites with certificates from that CA.
3. There is ongoing debate about the best way to handle expired certificates. The browsers could check with the CA for each access, but this would slow down the initial connection and heavily burden CA servers. Therefore it is rarely done. Some browsers maintain small lists of high profile expired or invalid certificates. Commercial certificates are usually issued for a year or more. Free (e.g. "lets encrypt") DV certificates are available which generally expire every 3 months.