How is a two-tier PKI hierarchy built, and what is each tier for?

An offline root CA signs only the certificates of one or more issuing (subordinate) CAs; the issuing CAs, which are online, sign all end-entity certificates.

• Tier 1: Root CA. Holds the trust anchor: a self-signed certificate that all clients trust. Its only job is to sign the certificates of the issuing CAs (and their CRLs). It is otherwise switched off or disconnected.
• Tier 2: Issuing (subordinate, intermediate) CA. Its certificate is signed by the root. It runs every day: it issues web server, user, code-signing and OCSP certificates, publishes CRLs and serves enrollment requests.

A client verifying a user certificate walks the chain: user certificate, signed by the issuing CA, whose certificate is signed by the root, which sits in the trust store.

Designs range from one tier (root issues everything: simple, but the root must stay online, which is risky) to three tiers (root, then policy CAs, then issuing CAs: for large organisations that need different policies or regions). Two tiers is the common middle ground: the root can stay offline, and several issuing CAs can serve different purposes (for example one for TLS, one for users) under one trust anchor.

* Two-tier hierarchy: the root only signs CAs, issuing CAs sign everything else. *

Go deeper:

• Microsoft: Designing and Implementing a PKI, Part I — the one-, two- and three-tier trade-offs from the AD CS team.
• Wikipedia: Chain of trust — how verification walks from leaf to root.