Issue Your First CA-Signed Certificate

Issue and verify CA-signed server and client certificates with OpenSSL.

Introduction

30 Second Summary

A signed visitor pass can show who approved entry. The person checking it still needs to confirm that every condition on the pass fits the situation.

In this project, you will use OpenSSL to build a two-certificate PKI hierarchy on your Mac. You will issue server.pki.test from a password-protected root certificate authority before testing exactly why verifiers accept or reject it.

What You'll Build

You will watch a server certificate fail without a trusted issuer before passing a strict verification check through your own root.

By the end of this project, you'll have:

  • A root certificate authority you can inspect for explicit certificate-signing permission.
  • A verified PKCS#10 certificate signing request for server.pki.test that becomes a separate purpose-limited server certificate.
  • A repeatable verification sequence where missing trust fails before server.pki.test succeeds through the root.
  • Secret Mission: Issue a client-only certificate that passes a client-purpose check but fails a server-purpose check through the same trusted root.

Are there any prerequisites?

You need a Mac with Homebrew installed. You should have completed Decode Your First X.509 Certificate or be comfortable with private keys, self-signed certificates, certificate decoding, and explicit trust anchors.

Before We Start

This checkpoint locks in what your certificate hierarchy proves before the hands-on work begins. You will connect a root certificate authority's approval to the separate checks a verifier performs.

Prepare a Fresh OpenSSL 3 Lab

Your certificate hierarchy needs a clean workspace because the earlier lab files are gone. Starting fresh prevents old keys or certificates from being mistaken for new project artifacts.

A Mac can resolve a different certificate utility when you type openssl. The certificate commands in this project depend on a specific version.

This step uses Homebrew to install the required OpenSSL 3.6.4 binary. A session-only PATH change makes that binary the one this Terminal resolves.

In this step, get ready to:
  • Confirm the required OpenSSL version is available through Homebrew.
  • Put the Homebrew binary first in the current Terminal session.
  • Create the empty ~/pki-issuance-lab workspace.
Resolve the correct OpenSSL binary

Your PATH controls which executable runs when several tools share the same command name. This temporary update applies only to the current Terminal session.

  • Select Homebrew's executable directory for this Terminal session by running these commands:
export PATH="$(brew --prefix openssl@3)/bin:$PATH"
openssl version

What do these commands do?

  • The first line places the formula's executable directory at the front of PATH for this Terminal session.
  • The second line asks the resolved openssl executable to report its version.

✔️ I see the required version

You see OpenSSL 3.6.4 in the output. The required formula is already installed and selected for this Terminal session.

ⓧ I see an older version

A lower or different version means this Terminal has not resolved the required Homebrew formula. Installing the current formula provides the version used throughout this project.

  • Install the current OpenSSL formula by running this command:
brew install openssl@3

What does this command do?

Homebrew downloads the openssl@3 formula. It installs the formula outside the macOS system tools.

  • Resolve the installed formula for this session by running the version commands again:
export PATH="$(brew --prefix openssl@3)/bin:$PATH"
openssl version

Why repeat the path command?

Installing the formula places its binary on your Mac. Updating PATH makes this Terminal choose that binary first.

You should now see OpenSSL 3.6.4 in the output.

ⓧ Command not found

This result means the required executable is unavailable through the current command path. The Homebrew formula supplies it.

  • Install the current OpenSSL formula by running this command:
brew install openssl@3

What does this command do?

Homebrew downloads the openssl@3 formula. It installs the required executable on your Mac.

  • Select the installed executable for this session by running the version commands again:
export PATH="$(brew --prefix openssl@3)/bin:$PATH"
openssl version

How does this select the executable?

The formula's executable directory moves to the front of PATH. The version line confirms which binary this Terminal now resolves.

You should now see OpenSSL 3.6.4 in the output.

Still seeing the wrong version?

  • Keep the same Terminal window open because the PATH update belongs to this session.
  • Confirm Homebrew completed the formula installation before repeating the version check.

Help me resolve the wrong OpenSSL version in this Terminal session.

Work inside an isolated folder

The lab folder keeps every future key or certificate in one local boundary. The mkdir command safely creates that folder when it does not already exist.

  • Prepare the workspace by running these commands:
mkdir -p ~/pki-issuance-lab
cd ~/pki-issuance-lab
pwd

What do these workspace commands do?

  • The mkdir command creates the local lab folder.
  • The cd command makes that folder your current Terminal location.
  • The pwd command prints the absolute path so you can confirm your location.

You should see a path ending in /pki-issuance-lab. This empty folder is now the workspace for the certificate hierarchy.

Path ending somewhere else?

  • Check that the path in your cd line points to ~/pki-issuance-lab.
  • Confirm that your Terminal session can create folders inside your home directory.

Help me reach the pki-issuance-lab workspace in macOS Terminal.

Close the setup loop

The final check tests both setup conditions in one run. It confirms the selected executable before printing the current workspace.

Before you run the final check, ask yourself which version line and folder ending you expect to see.

  • Verify the Terminal session and workspace by running:
openssl version && pwd

What does the final check prove?

  • The version line proves this Terminal resolves the required Homebrew OpenSSL binary.
  • The path line proves the lab folder is your current working directory.
  • The && operator prints the path only when the version check succeeds.

You should see OpenSSL 3.6.4 first. You should also see a path ending in /pki-issuance-lab.

Setup complete. This Terminal now points at the required OpenSSL binary inside the empty lab workspace.

Final check not matching?

  • Repeat the session path selection if the version differs from 3.6.4.
  • Return to ~/pki-issuance-lab if the printed path ends somewhere else.

Help me fix my final OpenSSL lab setup check.

Your clean lab is ready. Next, you will create a password-protected root certificate authority with explicit signing permissions.

Create a Real Root CA

Your fresh workspace now runs OpenSSL 3.6.4 from Homebrew. The empty lab is ready for its first root certificate authority.

A generic self-signed certificate proves possession of a private key. A root CA also needs X.509 extensions that explicitly authorize certificate signing.

In this step, get ready to:
  • Generate a password-protected root key plus its self-signed certificate.
  • Inspect the root certificate's identity plus its CA permissions.
  • Verify the root with root-ca.pem as the only explicit trust anchor.
Generate the root key and certificate

The private key is the root CA's signing authority. OpenSSL encrypts it with a passphrase.

A memorable temporary passphrase is enough for this local lab.

  • Choose a temporary lab passphrase that you can enter again later.
  • Store the temporary passphrase in a secure place for this lab.
  • Plan to enter the same passphrase twice when OpenSSL prompts you.
  • Generate the root key plus certificate by running this command:
openssl req -x509 -newkey rsa:2048 \
  -keyout root-ca.key \
  -out root-ca.pem \
  -days 365 \
  -subj "/CN=NextWork Lab Root CA" \
  -addext "basicConstraints = critical, CA:TRUE" \
  -addext "keyUsage = critical, keyCertSign, cRLSign"

What does this command create?

  • The -newkey rsa:2048 option creates a 2048-bit RSA private key in root-ca.key.
  • The -x509 option creates the self-signed root certificate in root-ca.pem.
  • The absence of -noenc keeps the new private key password-protected.
  • The -days 365 option gives the root certificate a 365-day lifetime.
  • The repeated -addext options place explicit CA authorization in the certificate.
  • Confirm the command returns to the shell prompt after both passphrase requests are complete.

The returned prompt confirms that OpenSSL finished generating the protected root key plus its self-signed certificate.

Did root generation stop early?

  • Complete both passphrase prompts with the same temporary value.
  • Rerun the generation command if the two passphrase entries did not match.
  • Confirm your Terminal remains in ~/pki-issuance-lab before rerunning the command.

Help me troubleshoot my root CA generation command.

Inspect the root identity and permissions

A self-issued root has the same subject plus issuer. Its CA extensions define what the certificate can authorize.

  • Inspect the root identity plus its CA extensions by running this command:
openssl x509 -in root-ca.pem -noout \
  -subject -issuer \
  -ext basicConstraints,keyUsage,subjectKeyIdentifier

What does this inspection show?

  • The -subject plus -issuer options reveal the certificate's self-issued identity.
  • The -ext basicConstraints,keyUsage,subjectKeyIdentifier option limits the report to the extensions relevant to CA authority plus key identification.
  • The Subject Key Identifier helps distinguish the public key represented by this certificate.
  • Confirm the Subject identifies CN=NextWork Lab Root CA.
  • Confirm the Issuer identifies CN=NextWork Lab Root CA.
  • Confirm Basic Constraints is critical.
  • Confirm Basic Constraints contains CA:TRUE.
  • Confirm Key Usage is critical.
  • Confirm Key Usage permits certificate signing plus certificate revocation-list signing.

You have now confirmed that the root is self-issued. Its critical extensions explicitly authorize CA work.

Don't see the expected CA fields?

  • Check that the certificate filename is spelled root-ca.pem.
  • Confirm your Terminal is still in ~/pki-issuance-lab.
  • Rerun the generation command if the certificate does not contain the required CA extensions.

Help me diagnose the missing root CA fields.

Verify the root with explicit trust

Chain verification begins with a trust anchor selected by the verifier. This check supplies root-ca.pem directly without changing macOS Keychain trust.

Before you run this check, do you expect the root to validate when it is also the only trust anchor?

  • Verify the root using only its certificate as the explicit trust anchor by running this command:
openssl verify -no-CApath -no-CAstore \
  -CAfile root-ca.pem root-ca.pem

What does this verification prove?

  • The -CAfile root-ca.pem option loads the root certificate as this command's explicit trust source.
  • The -no-CApath option disables the default certificate directory.
  • The -no-CAstore option disables the default certificate store.
  • The final root-ca.pem is the certificate being verified.
  • Confirm the output reports successful verification for root-ca.pem.

That's the foundation in place. Your root CA now verifies through the trust anchor you supplied for this command.

Did the root verification fail?

  • Confirm your Terminal is still in ~/pki-issuance-lab.
  • Check that both command references spell root-ca.pem exactly.
  • Repeat the inspection command to confirm the root still contains critical CA authorization extensions.

Help me troubleshoot the explicit root verification.

Your password-protected root CA is ready to approve a separate identity. Next, you'll create a server request from its own private key.

Build and Verify a Server CSR

Your root CA can now prove its own authority. The server needs a separate identity with a separate key before the CA can approve it.

A PKCS#10 certificate signing request carries the server's public key plus the identity being requested. In this step, OpenSSL creates that request without reusing the root CA key.

In this step, get ready to:
  • Generate a separate server key plus a CSR for server.pki.test.
  • Verify the CSR's self-signature before treating it as valid input.
  • Inspect the requested server identity in the CSR report.
Prepare the server identity

The root CA key represents the issuer. A new server key gives server.pki.test its own cryptographic identity.

  • Generate the server key plus its CSR by running this command in the Terminal session from earlier:
openssl req -new -newkey rsa:2048 -noenc \
  -keyout server.key \
  -out server.csr \
  -subj "/CN=server.pki.test" \
  -addext "subjectAltName = DNS:server.pki.test"

What does this command create?

  • The -new -newkey rsa:2048 -noenc options create a fresh 2048-bit RSA key without encryption for this local server identity.
  • The server.key file holds the server's private key.
  • The server.csr file holds the request that the root CA can review later.
  • The -subj "/CN=server.pki.test" option sets the requested subject.
  • The -addext "subjectAltName = DNS:server.pki.test" option requests the server's DNS identity.
  • Confirm the command finishes after showing key-generation progress.
  • Confirm Terminal returns to the prompt inside ~/pki-issuance-lab.

Did the generation command fail?

  • Check that each continued line ends with a backslash exactly as shown.
  • Confirm the current Terminal prompt still points to ~/pki-issuance-lab before retrying.

Help me fix a failed server key and CSR generation command.

Prove control of the server key

A CSR signs its own request data with the matching private key. Verifying that signature proves the request was created by whoever controls server.key.

This check does not grant CA approval. It confirms that the request is internally valid before issuance.

  • Verify the CSR's self-signature by running this command:
openssl req -in server.csr -noout -verify

What does this verification prove?

  • The -in server.csr option selects the request you just created.
  • The -verify option checks the request's self-signature against its embedded public key.
  • The -noout option keeps the encoded request out of the report.

The terminal reports that self-signature verification succeeded. That proves the request matches the private key that signed it.

Did the CSR verification fail?

  • Confirm the command reads server.csr from ~/pki-issuance-lab.
  • Regenerate the request if its contents changed after it was signed.

Help me diagnose a failed CSR self-signature check.

Read what the server is requesting

The self-signature proves control of the request. The decoded report shows the identity plus the extension that the server wants the CA to approve.

  • Decode the CSR's subject plus its detailed request data by running this command:
openssl req -in server.csr -noout -subject -text

What does this report contain?

  • The -subject option displays the requested certificate subject.
  • The -text option decodes the public-key details plus the requested extensions.
  • The report contains public request data. It does not display the private key from server.key.
  • Locate CN=server.pki.test in the subject.
  • Confirm the public-key section describes a 2048-bit RSA key.
  • Locate DNS:server.pki.test in the requested extensions.

Missing the requested SAN?

  • Confirm you inspected server.csr instead of root-ca.pem.
  • Regenerate the CSR if the requested extension does not contain DNS:server.pki.test.

Help me find the requested SAN in my CSR report.

Before the final check, do you expect one report to confirm the request's signature plus its requested identity?

  • Run the combined verification report by entering this command:
openssl req -in server.csr -noout -verify -subject -text

What does the combined check prove?

  • The -verify option confirms that the request's self-signature is valid.
  • The -subject option identifies the server named by the request.
  • The -text option exposes the requested DNS identity for review.

You will see that the request verifies successfully. The report also shows CN=server.pki.test plus DNS:server.pki.test under the requested extensions.

Does the final report look incomplete?

  • Confirm every option from the combined command appears on the same command line.
  • Scroll through the complete report to find the requested extensions near the end.
  • Regenerate server.csr if its subject or requested DNS identity differs from the expected values.

Help me compare my final CSR report with the expected identity.

Your server now has its own private key plus a verified request for server.pki.test. Next, the root CA can approve that request as a constrained server certificate.

Issue the Leaf and Hit the Trust Wall

Your verified PKCS#10 certificate signing request proves that server.key authorized the request for server.pki.test. The request still carries no approval from your root CA.

Now OpenSSL can turn that request into a leaf certificate. The issuing command binds the requested identity to the constraints approved by your CA.

A signed leaf still needs a trust anchor before a verifier can accept its chain. This step deliberately tests the new certificate without one.

In this step, get ready to:
  • Issue server.pem from the verified server request.
  • Inspect the certificate's identity plus its approved X.509 constraints.
  • Disable every default trust source to reproduce the missing-issuer failure.
Issue the constrained server certificate

This command uses the most sensitive file in the lab. The encrypted root-ca.key stays local while it signs one certificate.

  • Keep the temporary lab passphrase from the root CA step ready for the OpenSSL prompt.
  • Bind the approved certificate policy to server.csr by running this command:
openssl req -in server.csr \
  -CA root-ca.pem \
  -CAkey root-ca.key \
  -days 30 \
  -addext "basicConstraints = critical, CA:FALSE" \
  -addext "keyUsage = critical, digitalSignature, keyEncipherment" \
  -addext "extendedKeyUsage = serverAuth" \
  -addext "subjectAltName = DNS:server.pki.test" \
  -out server.pem

What does this signing command do?

  • The -CA option names root-ca.pem as the certificate issuer.
  • The -CAkey option uses root-ca.key to create the CA signature.
  • The -days 30 option limits the issued certificate to 30 days.
  • Each -addext entry records a constraint approved by the CA.
  • OpenSSL writes the issued leaf certificate to server.pem.
  • OpenSSL also creates root-ca.srl to store the next serial value for certificates issued by this root.
  • Confirm that Terminal returns to its prompt without reporting a signing error.

That is the sensitive part complete. Your root CA has approved a separate server identity in server.pem.

Certificate not created?

  • Rerun the signing command if the passphrase prompt was dismissed.
  • Enter the retained temporary lab passphrase exactly when prompted.
  • Confirm that Terminal is still in ~/pki-issuance-lab if OpenSSL cannot find an input file.

Help me diagnose why OpenSSL did not create server.pem from my verified CSR.

Inspect the certificate's approved constraints

A CSR proposes an identity. The issued certificate shows the policy that the CA actually approved.

  • Display the issued identity plus its approved extensions by running this command:
openssl x509 -in server.pem -noout \
  -subject -issuer \
  -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName,authorityKeyIdentifier

How do you read this certificate?

  • The subject identifies server.pki.test as the certificate holder.
  • The issuer identifies NextWork Lab Root CA as the signer.
  • The critical Basic Constraints value of CA:FALSE makes this an end-entity certificate.
  • The critical Key Usage field permits digitalSignature plus keyEncipherment.
  • The Extended Key Usage value of serverAuth permits TLS server authentication.
  • The Subject Alternative Name contains DNS:server.pki.test as the approved DNS identity.
  • Compare the subject with server.pki.test.
  • Compare the issuer with NextWork Lab Root CA.
  • Check the extension report against the approved constraints from the signing command.

You should see a separate subject plus issuer. You should also see CA:FALSE in the certificate policy.

The usage fields should include digitalSignature plus keyEncipherment. The report should also include serverAuth plus DNS:server.pki.test.

Certificate fields look different?

  • Confirm that the inspection command reads server.pem.
  • Check the earlier signing command for every repeated -addext option.
  • Rerun the signing command if an approved extension was omitted.

Help me compare my server.pem report with the approved server certificate policy.

Expose the missing trust anchor

The leaf now has the correct issuer signature plus approved constraints. This verification check supplies no trusted CA that can complete the path.

Before you run this check, do you think the verifier will accept the leaf when no trusted CA is available?

  • Remove every default trust source from the check by running this command:
openssl verify -no-CAfile -no-CApath -no-CAstore server.pem

What does this verification prove?

  • The -no-CAfile option disables the default CA file.
  • The -no-CApath option disables the default CA directory.
  • The -no-CAstore option disables the default CA store.
  • No -CAfile option supplies root-ca.pem as an explicit trust anchor.
  • OpenSSL reports unable to get local issuer certificate because it cannot locate a trusted issuer for the leaf.

You have reached the intended trust wall. The certificate is signed.

The verifier still has no trusted path to its issuer. Issuance alone does not establish trust.

Seeing a different result?

  • Confirm that the command includes all three options that disable default trust sources.
  • Confirm that the command tests server.pem.
  • Check that Terminal is still using Homebrew OpenSSL in the session from earlier.

Help me diagnose why my trust-free verification produced a different result.

Your server leaf now carries an approved identity plus a constrained purpose. Next, you will supply the root certificate as the trust anchor and test whether the trusted leaf matches the requested hostname.

Complete the Trust Path and Check Identity

Your root certificate authority issued server.pem as a separate X.509 leaf certificate. The failed verification proved that a signed leaf still needs a trusted issuer.

Adding root-ca.pem as a trust anchor gives OpenSSL a path to the issuer. Certificate acceptance still depends on hostname verification.

Strict verification also checks whether the certificate permits TLS server use. Each trust decision stays inside the command, so your macOS Keychain remains unchanged.

In this step, get ready to:
  • Test a trusted chain against wrong.pki.test.
  • Verify server.pem for the approved server hostname.
  • Compare the server issuer with the root subject.
Test the trusted certificate against another hostname

The Subject Alternative Name in server.pem contains DNS:server.pki.test. The verifier compares that approved identity with the hostname requested on the command line.

Before you run this check, do you expect a trusted signature to be enough for the certificate to represent wrong.pki.test?

  • Test the trusted certificate against wrong.pki.test by running this command:
openssl verify -no-CApath -no-CAstore \
  -CAfile root-ca.pem \
  -x509_strict \
  -purpose sslserver \
  -verify_hostname wrong.pki.test \
  server.pem

What does this check prove?

  • The -CAfile option supplies root-ca.pem as the explicit trust anchor.
  • The -no-CApath option disables the default certificate directory.
  • The -no-CAstore option disables the default certificate store.
  • The -x509_strict option applies strict certificate checks to the chain.
  • The -purpose option checks whether the leaf permits sslserver use.
  • The -verify_hostname option compares wrong.pki.test with the certificate identity.

You'll see a verification failure that includes hostname mismatch. The trusted root completed the path.

The requested hostname failed the identity check. This intended failure exposes the boundary between trust and identity.

Seeing a different result?

  • Confirm that your Terminal is still in ~/pki-issuance-lab.
  • Check that the command uses wrong.pki.test as the requested hostname.
  • Check that root-ca.pem remains in the current directory.

Why did my hostname verification produce a different result?

Complete the trusted server check

The certificate SAN contains server.pki.test. Its Extended Key Usage permits TLS server authentication.

Before you run the strict check, do you expect the same trusted chain to pass when the requested hostname matches the SAN?

  • Verify the approved server identity through the explicit root trust anchor by running this command:
openssl verify -no-CApath -no-CAstore \
  -CAfile root-ca.pem \
  -x509_strict \
  -purpose sslserver \
  -verify_hostname server.pki.test \
  -show_chain \
  server.pem

How does the final check work?

  • The -CAfile option supplies the root certificate that completes the trust path.
  • The -x509_strict option enforces strict X.509 requirements.
  • The -purpose option applies the sslserver policy to the leaf certificate.
  • The -verify_hostname option checks the approved server.pki.test identity.
  • The -show_chain option displays the path that OpenSSL successfully built.

That is the trust wall cleared. OpenSSL accepts server.pem for the approved hostname under the server policy.

The chain display links the server leaf to NextWork Lab Root CA. The root certificate is the only supplied trust anchor.

Strict verification not succeeding?

  • Confirm that the hostname is server.pki.test.
  • Confirm that the purpose is sslserver.
  • Check that the trust file is root-ca.pem.

Why is my strict server verification failing?

Successful chain building relies on linked certificate identities. The server certificate's issuer should match the root certificate's subject.

  • Compare the server certificate with the root certificate by running these inspection commands:
openssl x509 -in server.pem -noout -subject -issuer
openssl x509 -in root-ca.pem -noout -subject -issuer

How do these identities link?

  • The server.pem inspection prints the leaf subject plus the CA that issued it.
  • The root-ca.pem inspection prints the root subject plus its self-issued identity.
  • A matching server issuer and root subject provide the name link used to build this two-certificate path.

You'll see that the issuer of server.pem names NextWork Lab Root CA. The subject of root-ca.pem names the same certificate authority.

Certificate identities not lining up?

  • Confirm that the first inspection targets server.pem.
  • Confirm that the second inspection targets root-ca.pem.
  • Check that both files come from the current ~/pki-issuance-lab workspace.

Why do my server issuer and root subject differ?

Your server.pem certificate now reaches the explicit root trust anchor. It also passes the server-purpose check.

The certificate passes hostname verification for server.pki.test. Your macOS Keychain remains unchanged.

Secret mission

Prove Trust Does Not Grant Every Purpose

Issue a client-only certificate from your existing root CA. Then test the same trusted chain against two certificate purposes to prove that trust cannot override Extended Key Usage.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the lab, pause your work, or delete its local resources. This project has no running service or ongoing cost.

Resources you used:

  • The local ~/pki-issuance-lab directory contains your root CA files plus the server and client certificate artifacts.
  • The Homebrew OpenSSL formula openssl@3 is installed at version 3.6.4.

Keep everything running

No action is needed. Choose this if you want to extend the certificate hierarchy in a later project.

  • Keep ~/pki-issuance-lab in your home folder.
  • Retain the temporary root-key passphrase in your secure storage.
  • Leave openssl@3 installed for future certificate projects.

Pause - I'll come back to this later

Pausing ends the session-only PATH change. Your keys and certificates remain available on disk.

  • Close the current Terminal window.

No local service needs to be stopped. Opening a new Terminal session later gives you a fresh shell without the temporary OpenSSL path change.

Delete - I don't want to use this again

Deleting the lab removes every private key, request, certificate, and serial file you created. Keep the folder if you plan to issue more certificates from this root.

The root certificate never entered macOS Keychain. You have no system trust entry to remove.

  • Remove the Homebrew OpenSSL formula only if no other project needs it by running this command in the current Terminal session:
brew uninstall openssl@3

What Does This Command Do?

Homebrew removes the installed openssl@3 formula from your Mac. The command leaves the certificate files in ~/pki-issuance-lab untouched.

  • Read the final Terminal lines to confirm that Homebrew removed openssl@3.

Cannot Remove the Formula?

  • Keep openssl@3 installed if Homebrew reports that another installed package depends on it.

Help me understand why Homebrew will not uninstall openssl@3.

Every project artifact sits inside ~/pki-issuance-lab. Moving that folder to Trash removes the complete lab from its current location.

  • Press Cmd+Space to open macOS search.
  • Type Finder in the search field.
  • Press Enter to open Finder.
  • Select your home folder in the Finder sidebar.
  • Select pki-issuance-lab.
  • Choose Move to Trash.
  • Confirm that pki-issuance-lab no longer appears in your home folder.

Cleanup complete. Your lab created no cloud resources or persistent Keychain trust settings.

Nice Work!

Nice Work!

Excellent work on completing your local certificate hierarchy. Your PKI lab now uses OpenSSL to issue constrained certificates whose trust, hostname identity, and purpose you can test independently.

You've learned how to:

  • Create a password-protected root CA with critical Basic Constraints and Key Usage extensions that authorize certificate signing.
  • Verify a PKCS#10 CSR before treating it as an issuance request. Issue a separate X.509 server certificate for server.pki.test from that request.
  • Reproduce a missing-trust failure with every default trust source disabled. Test hostname verification against wrong.pki.test and server.pki.test to prove identity remains independent from chain trust.
  • Secret Mission: Issue a client-only certificate with Extended Key Usage restricted to client authentication. Prove the same trusted chain passes sslclient verification while failing sslserver verification with unsuitable certificate purpose.

Ready to quiz yourself?