Decode Your First X.509 Certificate

Generate, decode, and verify a self-signed X.509 certificate with OpenSSL.

Introduction

30 Second Summary

A file full of scrambled-looking text can decide whether a computer trusts an identity. Until you inspect it, every claim inside stays hidden.

In this project, you will build a local certificate laboratory with OpenSSL 3. You will connect an encrypted RSA private key to a self-signed X.509 certificate before testing signature validity against trust.

What You'll Build

You will watch the same certificate fail against an empty trust store before passing with a trust anchor you chose.

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

Create a protected identity: Generate a password-protected RSA private key with its matching self-signed certificate.
Turn encoded text into evidence: Read a certificate report covering identity, lifetime, public-key details, extensions, plus signature details. Compare two extracted public keys through matching SHA-256 digests.
Test trust on demand: Watch verification fail with an empty trust store. Supply your certificate as the explicit trust anchor to see verification pass.
Secret Mission: Corrupt the certificate signature deliberately. Prove that trust cannot rescue altered certificate data.

Are there any prerequisites?

You need a Mac with Homebrew plus OpenSSL 3 already installed. Everything runs locally in Terminal without an online account.

Before We Start

This first checkpoint helps you commit to what you are building before the hands-on work begins. You will connect each certificate test to the question it answers.

Prepare the Local Lab

Certificate experiments create several files that can be easy to confuse with older copies. A fresh folder keeps every result in this project isolated.

You will use Terminal to create the workspace. You will then confirm that OpenSSL 3 is the executable running inside it.

In this step, get ready to:

Open Terminal on your Mac.
Create the ~/pki-certificate-lab workspace as your current folder.
Confirm the active OpenSSL major version from inside the workspace.

Enter the lab workspace

Your lab needs one dedicated location for every key and certificate created later. Terminal keeps subsequent commands inside that location once it becomes the current folder.

Press Command-Space bar to open Spotlight.
Type Terminal into the search field.
Press Return to open Terminal.
Create the workspace as Terminal's current location by running this command:

mkdir -p ~/pki-certificate-lab && cd ~/pki-certificate-lab

What Does This Command Do?

The mkdir command creates the ~/pki-certificate-lab folder.
The -p option creates any missing path components.
The && operator continues only after folder creation succeeds.
The cd command makes the new folder Terminal's current working location.

Wait for Terminal to return to a fresh prompt.

A fresh prompt with no error text confirms that the folder was created successfully. Terminal is now working inside ~/pki-certificate-lab.

Workspace Command Failed?

Compare your command with the block above. Check the folder name for missing characters before running it again.

If Terminal still reports a problem, ask for help diagnosing the workspace command.

Confirm OpenSSL 3

Version output identifies the toolkit that Terminal resolves through your shell environment. This check prevents another TLS toolkit from distorting the certificate experiment.

Before you run the check, what version family do you expect the first words to identify?

Confirm the active OpenSSL version from inside the lab folder by running this command:

openssl version

What Does This Check?

The openssl executable prints its version information.
The first words identify the OpenSSL major version available through your shell.
This project uses OpenSSL 3.6.4 as its reference environment.

You will see output that begins with OpenSSL 3.

Your clean workspace is ready for every certificate experiment ahead.

Version Starts Differently?

Compare the command with the block above. Remove any extra characters before running it again.

If the output still identifies another major version, your shell is resolving a different executable. Ask for help connecting your shell to the installed OpenSSL 3 executable.

Your workspace is isolated with OpenSSL ready inside it. Next, you will generate the lab's private key and self-signed certificate.

Generate a Self-Signed Certificate

Your local certificate lab is ready. It still needs a real key pair before certificate fields have anything concrete to describe.

You will use OpenSSL to create an encrypted 2048-bit RSA private key. The same operation creates a self-signed X.509 certificate containing the matching public key plus your chosen identity.

In this step, get ready to:

Generate an encrypted 2048-bit RSA private key.
Create its matching self-signed certificate with PKI Lab Certificate as the Common Name.
Display the certificate subject from the finished file.

Create the encrypted key pair

A self-signed certificate carries claims signed by its matching private key. OpenSSL keeps that private key encrypted in key.pem.

The temporary lab passphrase protects your local key.pem. The project never needs this passphrase to be shared.

The command pauses for the passphrase. It then collects the certificate identity through a series of subject prompts.

Launch the interactive certificate request by running this command:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem

What Does This Command Create?

The -newkey rsa:2048 option creates a new 2048-bit RSA key pair.
The -keyout key.pem option writes the encrypted private key to key.pem.
The -x509 option makes the new certificate self-signed.
The -out cert.pem option saves the certificate as cert.pem.

Enter a temporary lab passphrase when OpenSSL requests one.
Enter the same passphrase for confirmation.
Complete the subject prompts with your own lab values.
Use PKI Lab Certificate specifically for the Common Name.
Keep the temporary lab passphrase available for later private-key operations.
Wait for Terminal to return to its command prompt.

Good progress. When the Terminal prompt returns, key.pem contains your encrypted private key.

The matching self-signed certificate is stored in cert.pem.

Generation Stopped Early?

If OpenSSL is still waiting for input, complete the current subject prompt so the command can continue.

If the passphrase confirmation does not match, run the generation command again. Use the same temporary passphrase both times.

Help me diagnose the missing certificate files.

Display the certificate subject

The subject records the identity placed inside the certificate. Reading it proves that OpenSSL can parse cert.pem.

Before the check, consider which subject information OpenSSL will read from cert.pem.

Ask OpenSSL to read the certificate subject by running this command:

openssl x509 -in cert.pem -noout -subject

What Does This Command Read?

The -in cert.pem option selects the certificate in your lab folder.
The -noout option suppresses the encoded certificate output.
The -subject option prints the distinguished name stored in the certificate.

You should see the subject information you entered. The displayed Common Name includes PKI Lab Certificate.

That confirms your first certificate is readable. Its identity now appears directly from cert.pem.

Subject Missing or Unexpected?

If OpenSSL cannot read cert.pem, confirm that the generation command reached the Terminal prompt without stopping early.

If the Common Name differs, run the generation command again. Enter PKI Lab Certificate at the Common Name prompt.

Help me troubleshoot the certificate subject.

Your encrypted key plus its self-signed certificate are ready. Next, you will prove that both belong to the same key pair.

Prove the Key and Certificate Match

The X.509 certificate from the last step contains identity claims. Those claims become useful when you can connect its embedded public key to the encrypted private key you control.

In this step, you will use OpenSSL to extract a SubjectPublicKeyInfo public key from each file. Matching SHA-256 digests prove that cert.pem carries the public key associated with key.pem.

In this step, get ready to:

Extract the public key from key.pem.
Extract the SubjectPublicKeyInfo block from cert.pem.
Compare both files with SHA-256 digests.

Extract the private key's public half

An encrypted private key can produce its public half without exposing its private material. The passphrase stays inside OpenSSL's prompt instead of appearing in the command or a project file.

Keep your temporary lab passphrase ready for the prompt.
Write the public half of key.pem to pubkey.pem by running:

openssl pkey -in key.pem -pubout -out pubkey.pem

What does this command do?

The -in key.pem option selects the encrypted private key.
The -pubout option exports only the public components.
The -out pubkey.pem option stores the extracted public key in a separate file.

Enter your temporary lab passphrase when Terminal asks for it.
Confirm that Terminal returns to its prompt without reporting a failure.

Your first extraction is complete. The new pubkey.pem file contains the shareable public half derived from your encrypted key.

Passphrase not accepted?

Re-enter the temporary lab passphrase you chose when creating key.pem.
Confirm that your Terminal session still uses ~/pki-certificate-lab as its current folder.

Help me troubleshoot why OpenSSL cannot extract the public key from my encrypted key file.

Extract the certificate's public key

A certificate carries its public key in readable form. OpenSSL can export it without the passphrase because cert.pem contains no private material.

Write the certificate's public key to cert-pubkey.pem by running:

openssl x509 -in cert.pem -pubkey -noout -out cert-pubkey.pem

What does this command do?

The -in cert.pem option selects your self-signed certificate.
The -pubkey option extracts its SubjectPublicKeyInfo block.
The -noout option suppresses the encoded certificate output.
The -out cert-pubkey.pem option stores the extracted public key in its own file.

Confirm that Terminal returns to its prompt without reporting a failure.

You now have two public-key files from independent paths. The pubkey.pem file came from the private key. The cert-pubkey.pem file came from the certificate.

Certificate public key not extracted?

Confirm that cert.pem remains inside ~/pki-certificate-lab.
Repeat the certificate extraction command after checking the filename for typing mistakes.

Help me diagnose why OpenSSL cannot extract the public key from my certificate.

Compare the public-key digests

A SHA-256 digest acts as a compact fingerprint of each extracted PEM block. Identical digest values show that both files encode the same public key.

Before you run the comparison, do you expect the two digest values to match?

Calculate both digests by running:

openssl dgst -sha256 pubkey.pem cert-pubkey.pem

What does this command do?

The -sha256 option selects the SHA-256 digest algorithm.
OpenSSL calculates one digest for pubkey.pem.
OpenSSL calculates a separate digest for cert-pubkey.pem.

You'll see one SHA-256 digest for each file. The two hexadecimal digest values are identical.

That match closes the loop. You now have direct evidence that the certificate contains the public half of the private key you control.

Digest values do not match?

Repeat both extraction commands above to replace the public-key files.
Confirm that both extraction commands use the current key.pem and cert.pem files.
Run the digest comparison again after both extractions succeed.

Help me find why the public keys extracted from my private key and certificate have different SHA-256 digests.

Your certificate is now tied to the private key with reproducible evidence. Next, you'll decode its fields before testing how an empty trust store responds.

Decode the Certificate and Test Empty Trust

Your matching SHA-256 digests proved that cert.pem carries the public key paired with key.pem. The next question is what the certificate claims about its identity.

In this step, you will use OpenSSL to decode the X.509 certificate into readable fields. You will then isolate certificate verification from every default trust source to expose the missing trust anchor.

In this step, get ready to:

Decode cert.pem into a readable certificate report.
Produce a focused identity and validity summary.
Trigger an intentional verification failure with an empty trust store.

Decode the full certificate

A PEM certificate stores structured data inside encoded text. OpenSSL can expand that data into a report that exposes each certificate claim.

Decode the complete certificate report by running this command:

openssl x509 -in cert.pem -noout -text

What Does This Command Show?

The x509 operation reads and displays certificate information.
The -in cert.pem option selects your certificate as the input.
The -noout option suppresses another copy of the encoded certificate.
The -text option expands the certificate into readable details.

Locate the certificate version near the top of the report.
Locate the serial number assigned during generation.
Locate the signature algorithm used to sign the certificate.
Locate the issuer that signed the certificate.
Locate the validity period.
Locate the subject that identifies the certificate.
Locate the public-key details.
Locate the X.509 extensions near the lower part of the report.

You can now point to the identity, lifetime, key material, extensions, and signature details carried inside cert.pem.

Certificate Report Missing?

Confirm that Terminal is still working in ~/pki-certificate-lab.
Check that cert.pem appears in the lab folder.

Help me diagnose why OpenSSL cannot decode my certificate.

Summarize the certificate identity

The full report is useful when you need every detail. A focused view makes the certificate identity easier to compare.

Display the identity, serial number, and dates in a short report by running this command:

openssl x509 -in cert.pem -noout -subject -issuer -serial -dates

What Does This Summary Include?

The -subject option displays the identity named by the certificate.
The -issuer option displays the identity that signed the certificate.
The -serial option displays the certificate serial number.
The -dates option displays the beginning and end of the validity period.

Compare the subject line with the issuer line.

You will see the same distinguished name on both lines. That match is expected because cert.pem is a self-signed certificate.

Subject and Issuer Look Different?

Confirm that both lines came from the same cert.pem file.
Compare the Common Name and the other subject values character by character.

Help me compare the subject and issuer in my certificate output.

Test the certificate with no trust anchor

A trust store supplies the certificates that a verifier may accept as trust anchors. Removing every default trust source creates an isolated check of cert.pem.

Before you run the check, consider this question: will a valid self-signature be enough for the isolated verifier to accept cert.pem.

Test cert.pem with every default trust source disabled by running this command:

openssl verify -no-CAfile -no-CApath -no-CAstore cert.pem

What Does This Verification Show?

The -no-CAfile option disables the default trusted certificate file.
The -no-CApath option disables the default trusted certificate directory.
The -no-CAstore option disables the default trusted certificate store.
The final cert.pem identifies the certificate that OpenSSL verifies.
With no trust anchor available, OpenSSL reports self-signed certificate.

That failure is exactly what this test was designed to produce. You have separated readable certificate data from verifier trust.

Seeing a Different Result?

Check that -no-CAfile appears in the command.
Check that -no-CApath appears in the command.
Check that -no-CAstore appears in the command.

Help me diagnose my empty trust-store verification result.

Your certificate has revealed its claims and failed against an isolated trust store exactly as intended. Next, you will supply the missing trust anchor and watch the same certificate pass verification.

Supply the Trust Anchor

Your earlier verification isolated the certificate from every default trust source. OpenSSL reported self-signed certificate because the verifier had no approved trust anchor.

This step makes that missing decision explicit. You will supply cert.pem as a lab-only trust anchor for one verification command.

The macOS system trust store stays unchanged. The result applies only to the command you run.

In this step, get ready to:

Identify the missing trust-anchor decision behind the earlier failure.
Verify cert.pem with an explicit lab-only trust anchor.
Compare both verification outcomes.

Set the lab trust boundary

A verifier accepts a certificate chain when it reaches a certificate designated as trusted. Your self-signed cert.pem fills that role for this single command.

Leave the macOS system trust store unchanged.

Why keep trust local?

The -CAfile option loads a certificate file as a trust anchor for the current verification command. It lets you test a trust policy without installing the certificate into the macOS system trust store.

This keeps machine-wide trust untouched. Your experiment remains contained inside ~/pki-certificate-lab.

Verify with the explicit trust anchor

Before you run this, do you think the same certificate can move from failure to success without changing its contents?

Verify cert.pem against the explicit lab trust anchor by running this command:

openssl verify -no-CApath -no-CAstore -CAfile cert.pem cert.pem

What does this command prove?

The -no-CApath option removes default trusted certificate directories from this check.
The -no-CAstore option removes default trusted certificate stores from this check.
The -CAfile cert.pem option loads your certificate as the explicit trust anchor.
The final cert.pem is the certificate OpenSSL verifies.
The result cert.pem: OK confirms that the explicit anchor completes the trust path.

You have now made the trust decision visible. The certificate stayed unchanged.

The verifier's policy gained one explicit anchor. That policy change turned the earlier failure into success.

Verification still fails?

Confirm that the Terminal session is still working in ~/pki-certificate-lab.
Check that -CAfile cert.pem appears before the final cert.pem.
Help me diagnose why my explicit OpenSSL trust-anchor verification still fails.

Secret mission

Detect a Corrupted Signature

Create a readable certificate with a deliberately damaged signature. Then prove that trusting the original certificate cannot authenticate altered signed data.

Clean Up Your Resources

Your local OpenSSL certificate lab uses only files on your Mac. Decide whether to keep the folder, pause by closing Terminal, or delete all five files.

Resources you used:

Encrypted RSA private key at ~/pki-certificate-lab/key.pem.
Self-signed X.509 certificate at ~/pki-certificate-lab/cert.pem.
Public key extracted from the private key at ~/pki-certificate-lab/pubkey.pem.
Public key extracted from the certificate at ~/pki-certificate-lab/cert-pubkey.pem.
Certificate with a deliberately corrupted signature at ~/pki-certificate-lab/broken.pem.

Keep everything running

No action needed. Choose this if you want to reuse the certificate as a trust anchor in the next project.

Leave ~/pki-certificate-lab in your home folder.

Pause - I'll come back to this later

Your lab leaves no process or service running. The five files remain available at no ongoing cost.

Close the Terminal window from earlier.

Delete - I don't want to use this again

This option removes the entire local lab from your home folder. Your macOS system trust store needs no cleanup because this project never changed it.

Deletion Is Permanent

Deleting the folder removes its encrypted private key and all certificate evidence together. Keep the folder if you plan to continue with the next project.

Press Cmd+Space to open macOS search.
Type Finder into the search field.
Select Finder from the search results.
Select your home folder in the Finder sidebar.
Locate pki-certificate-lab.
Move pki-certificate-lab to Trash.
Confirm that pki-certificate-lab no longer appears in your home folder.
Close the Terminal window from earlier.

Nice Work!

You did it! You built a local X.509 certificate lab that turns opaque PEM text into evidence you can inspect.

You've learned how to:

Generated an encrypted RSA private key with a matching self-signed certificate.
Proved the key-certificate match through identical SHA-256 digests from two independently extracted public keys.
Decoded a readable certificate report covering identity, validity, public-key, extension, plus signature details. Demonstrated isolated trust validation by changing the same certificate from untrusted to trusted with an explicit lab-only trust anchor.
Secret Mission: Created a readable certificate with a deliberately corrupted signature. Proved that verification rejects it against the trusted original.

Ready to quiz yourself?