How does a new subordinate CA get its own certificate from the root CA?

It creates a key pair and a CSR, the root signs that CSR into a CA certificate, and the subordinate installs the returned certificate chain before it can start.

1. Generate a key pair on the subordinate CA (here RSA 4096 bit, SHA-256) and give the CA a meaningful name ("CKTECK CA").
2. Create a Certificate Signing Request (CSR) and save it to a file. The private key never leaves the subordinate.
3. Submit the CSR to the root (here through the root's /certsrv web enrollment page, using the "Subordinate Certification Authority" template).
4. An administrator approves the request on the root. The lab root issues automatically so that many groups can share it, a setting that must never be used outside a lab: anyone who can reach the page would get a CA certificate.
5. Download the issued certificate as a chain (.p7b, which includes the root certificate) and install it on the subordinate ("Install CA Certificate"). The warning "the root certificate is untrusted" is expected until the root is published as trusted.
6. Start the CA service. Only now can it issue certificates, and each one it issues chains up to the root.

The same request-sign-install pattern repeats for every certificate in the topic: web server, users, code signing, even mitmproxy's own CA.

Go deeper:

• Microsoft: Designing and Implementing a PKI, Part I — where the subordinate's request fits into a full PKI rollout.
• Wikipedia: Certificate signing request — what the request file contains.