PKCS#1 vs PKCS#8 vs SPKI: decoding private and public key labels without guessing
Understand common PEM labels and the structures they represent so you can stop renaming files and start importing the right thing.
Tip
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
PEM labels are clues, not decoration. They tell you what structure is inside the file, whether it is private or public, and which parsers are likely to accept it.
A lot of key-import pain comes from treating every PEM block as interchangeable because it starts with BEGIN and ends with END.
Summary
Definition: PKCS#1 commonly describes RSA-specific key structures, PKCS#8 describes a private-key container that can wrap multiple algorithm families, and SPKI is the common public-key structure used in certificates and many PEM public-key files.
Why it matters: Import errors often come from feeding a parser the wrong structure, not the wrong algorithm.
Pitfall: Changing a file name or a PEM label by hand does not convert the ASN.1 structure inside.
Container type and algorithm are separate questions
A parser may care both about the algorithm family and about the key container. PKCS#8 can hold an RSA or EC private key. SPKI can describe an RSA or EC public key. That is why “it is an RSA key” is sometimes not enough to satisfy the import path.
The key insight is to answer two questions independently: is this public or private, and what structure is wrapping it?
Read the label, then verify the structure
Labels such as BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY, and BEGIN PUBLIC KEY are useful hints. They are not infallible if someone copied content badly, but they usually tell you whether you are looking at PKCS#8, RSA-specific PKCS#1, or a public-key container. A key inspector is valuable because it confirms the inside, not just the text wrapper.
This matters in JOSE, OpenSSL, and certificate tooling alike. The wrong wrapper can look close enough to mislead you until import fails.
BEGIN RSA PRIVATE KEYoften points to PKCS#1.BEGIN PRIVATE KEYcommonly points to PKCS#8.BEGIN PUBLIC KEYcommonly points to SPKI.
Why this belongs in a focused toolset
A key inspector fits this workflow because the job is one question: what is this key blob really? Once the answer is visible, conversion and verification become much less dramatic.
Quick example
Use this when a parser accepts one PEM block but rejects another that looks almost the same.
What to notice: The labels are only the first clue. The point is to match structure to parser expectations.
BEGIN RSA PRIVATE KEY -> RSA-specific private-key structure
BEGIN PRIVATE KEY -> PKCS#8 private-key structure
BEGIN PUBLIC KEY -> SPKI public-key structure
Practical check
- Separate public/private questions from structure questions.
- Read the PEM label, then confirm the inside with a structure-aware tool.
- Do not rename files or labels and call that conversion.
FAQ
Is PKCS#8 only for RSA?
No. It is a general private-key container that can carry different algorithm families.
Can SPKI contain a private key?
No. SPKI is for public-key information.
Developer workflow
Use this guide as an operations checklist before changing certificates, tokens, DNS, or deployment settings.
- Inspect the current artifact or endpoint output before making changes.
- Change one variable at a time so a failed verification has a narrow cause.
- Keep the rollback value, expiry, and verification command in the same runbook entry.
1. current deployed artifact
2. single config or key change
3. verify endpoint/client behavior
4. record rollback and expiry details