🗝️Module 02 — Keys, Encodings & File Formats

-rw------- 1 zaeem zaeem  119 Aug 20 12:04 ed25519.key
-rw------- 1 zaeem zaeem  241 Aug 20 12:04 ec256.key
-rw------- 1 zaeem zaeem 1704 Aug 20 12:04 rsa2048.key
-rw------- 1 zaeem zaeem 3272 Aug 20 12:04 rsa4096.key

   3 ed25519.key
   5 ec256.key
  28 rsa2048.key
  54 rsa4096.key

What to read out of this.

• The size difference is enormous. The Ed25519 key is 119 bytes. The RSA-4096 key is 3,272 bytes — about 27 times bigger for no extra security. The EC key is 3 lines of text; the RSA key is 54.
• This is not just about disk space. The key ends up inside the certificate, and the certificate is sent on every single new connection. A smaller key means fewer bytes on the wire, every time, forever.
• All four files are 0600, because of the umask 077 from Module 01's Exercise D2.1. Good.

Now imagine this at 500 hosts. A busy site handles millions of new connections a day. Switching from RSA-4096 to EC P-256 removes roughly 3 KB from each one. That is real bandwidth and real time, and it costs you nothing in security.

# RSA 2048
real    0m0.184s

# RSA 4096
real    0m3.921s

# EC P-256
real    0m0.009s

What to read out of this.

• Your times will be different every single run. Generating an RSA key means guessing large numbers and testing whether they are prime. Sometimes you get lucky on the third guess, sometimes the hundredth. Run the 4096 command three times and you may see 1 second, then 9 seconds, then 4.
• EC generation is basically instant because there is no prime hunting involved. It just picks a random number in a range.
• RSA-4096 took roughly 20–40× longer than RSA-2048 for a security gain almost nobody needs.

🔑 Why this matters in real life. This is a classic cause of "the container takes ages to start". Something generates a fresh RSA-4096 key at boot, on a machine with a thin pool of randomness, and the startup hangs for 30 seconds while everyone hunts for a network problem that does not exist.

ECDSA with a P-256 key, for most public web servers in 2026. It gives the same security as RSA-3072 in a key roughly one twelfth the size, the certificate on the wire is smaller, and the signing operation the server does on every handshake is several times cheaper.

The part that shows real experience is knowing when not to: very old clients (Java 6/7, Windows XP, some payment terminals and embedded devices) do not support ECDSA. If you must serve those, the usual approach is a dual-certificate setup — nginx and Apache can both hold an RSA certificate and an ECDSA certificate at the same time and hand each client whichever it understands.

Worth adding: the key type is chosen when you generate the key, and changing it means a brand-new key and a brand-new certificate. It is not a config toggle.

No. Security does not scale with the number. RSA-2048 gives roughly 112 bits of security strength; RSA-4096 gives roughly 152. So you pay about 20–40× the key generation time and a permanently slower signing operation for a modest improvement that no realistic attacker is anywhere near.

RSA-2048 is still considered fine by NIST for general use. RSA-4096 makes sense for a root CA whose key must stay safe for 20 years, and rarely anywhere else.

The framing that lands well: "For a certificate that lives 90 days, key size is almost never the weakest link. Key storage is. I would rather spend the effort making sure the key is 0600, not in git, and rotated automatically."

Ed25519 is excellent — small, fast, and resistant to several classes of implementation mistake that have caused real bugs in ECDSA. SSH adopted it quickly because SSH controls both ends of the connection.

Public web certificates cannot move that fast. A CA may only issue key types listed in the CA/Browser Forum Baseline Requirements, and browsers must all support the type before it is useful. Ed25519 is not in that allowed set, so no public CA will issue you a certificate for one.

You can still use Ed25519 on a private internal CA, where you control every client — which is a good example of the general rule that internal PKI has far more freedom than public PKI. That comes back in Module 12.

Private-Key: (2048 bit, 2 primes)
modulus:
    00:bb:54:94:d4:b7:d5:2c:f1:c2:a3:85:f3:bc:e4:
    df:9a:71:0c:2e:88:14:6b:37:c9:d0:52:8f:e1:4a:
    ... (many more lines)
publicExponent: 65537 (0x10001)
privateExponent:
    3f:9a:2c:8e:5b:1d:47:f0:a6:c3:9e:82:b7:4d:10:
    ...
prime1:
    00:e2:8a:4f:1b:9c:07:d5:36:a8:11:c4:7e:93:2b:
    ...
prime2:
    00:d3:e0:91:7b:45:ca:28:f6:01:3b:7e:9d:5a:8c:
    ...
exponent1:
    ...

Private-Key: (256 bit)
priv:
    00:8f:2a:1c:74:b3:e9:05:d1:9c:44:f7:a1:2b:8e:
    60:33:a0:15:7d:3c:e2:b8:44:f9:a6:1d:8e:04:c7:
    b3:52:1f
pub:
    04:9c:8b:31:e7:0a:5d:64:2f:c8:19:b3:7a:e5:40:
    ...
ASN1 OID: prime256v1
NIST CURVE: P-256

What to read out of this.

• publicExponent: 65537 — and it will be 65537 on essentially every RSA key you ever see. It is not random. It was chosen because it is prime, and because in binary it is 10000000000000001 — only two 1-bits — which makes the maths fast. If you see a different value, someone did something unusual on purpose.
• prime1 and prime2 are the crown jewels. Multiply them together and you get the modulus. Anyone who obtains these two numbers owns your key completely. This is the actual thing you are protecting with chmod 600.
• The EC key is tiny by comparison — one priv number and one pub point, then the curve name. No primes, no exponents, no shortcuts. That simplicity is why the file was 241 bytes instead of 1704.
• NIST CURVE: P-256 — an EC key is meaningless without knowing which curve it lives on, so the curve name is stored in the file. prime256v1 and P-256 and secp256r1 are three names for the same curve, which is a genuinely annoying piece of trivia that catches everyone at least once.

IDENTICAL every time

private file says:
9e107d9d372bb6826bd81d3542a419d6  -
public file says:
9e107d9d372bb6826bd81d3542a419d6  -

What to read out of this.

• Deriving the public key is not a calculation, it is a copy. The modulus and exponent are already sitting in the private file. -pubout just writes them out on their own. That is why it is instant and why the result is identical every time.
• The two md5sum lines match. The private key and the public key share the same modulus — they are two views of one thing.
• Remember this trick. Comparing modulus hashes is exactly how you prove a key and a certificate belong together, which is Part D2 of this module and one of the most useful things you will learn all week.

💡 We used md5sum here purely to shorten a very long number for comparison. That is a fine use of MD5 — nobody is attacking it, we are just abbreviating. This is the exact nuance from Module 01's Exercise B4.2.

The public key is published inside the certificate. Anyone who connects receives it. The private key stays on the server, in a separate file, and is never sent anywhere.

During connection setup the server uses the private key to prove it holds the matching half — in modern TLS by signing part of the handshake. The client checks that signature using the public key from the certificate. An attacker can copy your certificate freely, but without the private key it cannot complete a handshake.

The detail worth adding: the public key is also stored inside the private key file, which is why you can always regenerate a public key or a CSR from a private key, but never the other way round. Lose the certificate and you can reissue; lose the private key and you must start over with a new key.

Because it is prime, it is large enough to avoid a family of attacks that affect very small exponents like 3, and in binary it has only two bits set — which makes the public-key operation fast.

It is effectively a fixed constant across the entire internet. Seeing anything else means somebody deliberately overrode it, and it is worth asking why.

Treat it as compromised. Fixing the permissions does not undo exposure, and there is no way to know whether it was read.

The response, in order: generate a brand-new key, issue a new certificate for it, deploy the new pair, then revoke the old certificate and remove the old key. Notice that revocation comes after the replacement is live, and that — as Module 01's Exercise D3.2 showed — revocation may not actually stop clients, so replacement is the part that genuinely protects you.

Then fix the cause: check whether the key is in git history (permanent — deleting the file does not remove it), check backups and log aggregation, and check whether the same key was reused on other hosts.

What separates a strong answer: saying plainly that you cannot "rotate a password" here. A leaked private key is unfixable except by replacement, and that fact is the whole argument for short certificate lifetimes and automated issuance.

-----BEGIN PRIVATE KEY-----
-----BEGIN ENCRYPTED PRIVATE KEY-----

Enter pass phrase for rsa2048-locked.key:
Private-Key: (2048 bit, 2 primes)
modulus:

What to read out of this.

• The header line changed from BEGIN PRIVATE KEY to BEGIN ENCRYPTED PRIVATE KEY. That one line is how every tool knows to ask you for a passphrase. You can tell at a glance, with head -1, whether a key file is locked.
• The file is now genuinely encrypted, not just marked. Open it in an editor and the Base64 is completely different from the original.
• Removing the passphrase is trivial if you know it. openssl pkey -in locked.key -out plain.key and it is gone. A passphrase protects the file at rest — against a stolen backup or a laptop — not against someone who already has the passphrase or who can read the key out of a running process's memory.

Enter pass phrase for rsa2048-locked.key:
Could not read private key from rsa2048-locked.key
4077A1B2C87F0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
exit code: 1

Private-Key: (2048 bit, 2 primes)

What to read out of this — this is the practical heart of A3.

With no human to type the passphrase, the read simply fails. That is exactly what happens to nginx, Apache, HAProxy or a Java service when it restarts at 3am with a passphrase-protected key: the service does not come up.

So teams do one of these things, and each has a cost:

1. No passphrase at all. By far the most common. The key is protected by 0600 and by whoever can reach the machine. Simple, and it restarts cleanly.
2. Passphrase in a file next to the key (ssl_password_file in nginx). This is security theatre — anyone who can read one file can read the other.
3. Passphrase supplied by a secret manager at boot — Vault, AWS Secrets Manager, systemd credentials. Real protection, real complexity.
4. Key never on disk at all — held in an HSM or a cloud KMS, so the server can use it but never read it. This is the strongest answer and the one to mention in interviews.

🔑 The honest summary: a passphrase protects a key at rest. On a running server the key must be usable without a human, so the passphrase usually ends up somewhere the attacker can also reach. That is why the industry moved toward short-lived keys and KMS/HSM storage instead of passphrases.

⚠️ Note the error message: unsupported ... store_result.c. It does not say "wrong passphrase" or "no passphrase given". This is the same terse, unhelpful style you met in Module 01's Exercise B5.2 — crypto tooling tells you that something failed, rarely why.

Layered, and worth giving in order of increasing strength:

• File level: 0600, owned by the service account, on a directory that is 0700. Never in git — and if it ever was, git history is permanent, so the key is burned.
• Generation: create the key on the machine that will use it. A key that has been emailed or pasted into Slack has been on someone's laptop and in a message archive.
• At rest: encrypt backups and disk. A passphrase on the key file helps here but breaks unattended restarts, so most teams use a secret manager instead.
• Best: the key never exists as a readable file. An HSM or cloud KMS performs signing operations on request and never exports the key. Compromising the server no longer means compromising the key.
• Blast radius: short certificate lifetimes and automated renewal, so a leaked key expires on its own.

The line that lands: "A private key that has been exposed cannot be un-exposed. So I optimise for making exposure both unlikely and short-lived, rather than relying on any single control."

Usually no, and being able to explain why not matters more than the answer.

A passphrase protects the key at rest. But a server must be able to start without a human, so the passphrase has to be readable by the machine — which usually means it sits in a file beside the key, where it protects nothing. You have added an outage risk for no real security.

The cases where a passphrase is right: a CA root key that is used deliberately and rarely, keys on developer laptops, and keys in transit. In those cases a human is present anyway.

The better answer to the underlying question: if the concern is a stolen key file, the real fixes are KMS/HSM-backed keys, full-disk encryption, and short-lived certificates — not a passphrase.

-rw------- 1 zaeem zaeem 138 Aug 20 12:41 ec256.der
-rw------- 1 zaeem zaeem 241 Aug 20 12:04 ec256.key

00000000: 3081 8702 0100 3013 0607 2a86 48ce 3d02  0.....0...*.H.=.
00000010: 0106 082a 8648 ce3d 0301 0704 6d30 6b02  ...*.H.=....m0k.
00000020: 0101 0420 8f2a 1c74 b3e9 05d1 9c44 f7a1  ... .*.t.....D..
00000030: 2b8e 6033 a015 7d3c e2b8 44f9 a61d 8e04  +.`3..}<..D.....

    0:d=0  hl=3 l= 135 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim: INTEGER           :00
    6:d=1  hl=2 l=  19 cons: SEQUENCE
    8:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim: OCTET STRING      [HEX DUMP]:306B0201010420...

What to read out of this.

• The DER file is 138 bytes; the PEM file was 241. The text version is about 75% bigger, because Base64 adds roughly a third and then line breaks and headers add more. DER is the compact truth; PEM is a readable wrapper around it.
• The very first byte is 30. That is the ASN.1 tag for SEQUENCE — "a box containing things". Nearly every certificate and key file in the world starts with 30, and that is a genuinely useful fact: xxd file | head -1 tells you instantly whether you are looking at DER.
• Read the asn1parse output as a nested list. d=0 is the outer box, d=1 is one level in, d=2 is two levels in. The outer SEQUENCE contains a version number, another SEQUENCE describing the algorithm, and an OCTET STRING holding the actual key material.
• id-ecPublicKey and prime256v1 are OIDs — Object Identifiers. They are globally unique numbers that name algorithms and fields, so that everybody agrees what "EC public key on curve P-256" means. OpenSSL is printing the friendly name; the file contains the number.

💡 openssl asn1parse is your X-ray machine. When a file will not load and you cannot tell why, running asn1parse on it tells you whether the internal structure is intact or genuinely corrupt.

Could not read private key from ec256.der
40C7B1E2A87F0000:error:1E08010C:DECODER routines::unsupported:crypto/encode_decode/decoder_lib.c:101:No supported data to decode. Input type: PEM

---

Could not read private key from ec256.key
40C7B1E2A87F0000:error:1E08010C:DECODER routines::unsupported:crypto/encode_decode/decoder_lib.c:101:No supported data to decode. Input type: DER

What to read out of this.

• Both failed, and the two errors are nearly identical apart from the last three characters: Input type: PEM versus Input type: DER.
• Those last three characters are the whole diagnosis. OpenSSL is telling you what form it expected. Input type: PEM means "I was told to read text and found something that is not text". So the fix is -inform DER.
• The file itself is perfectly fine in both cases. Nothing is corrupt. The tool was simply told the wrong thing.

🔑 Build this reflex now: when a key or certificate "will not load", your first question is not "is it broken?" It is "is it in the form the tool expects?" In practice that solves it more often than anything else, and you can check in one second with head -1 file.

Now imagine this at 500 hosts. A deployment pipeline that assumes PEM will fail on the one team that exported DER from a Windows tool. Making your scripts detect the form (head -c1 | xxd → does it start with 30?) rather than assume it is a five-line change that removes a whole category of ticket.

DER is a set of strict rules for writing ASN.1 data structures as bytes, where every value has exactly one valid encoding.

That uniqueness is the whole point. A CA signs the hash of the certificate's bytes. If the same certificate could legitimately be written two different ways, it would produce two different hashes, and a signature valid on one would fail on the other. DER removes that ambiguity.

Where this bites in real life: it is also why you must never "tidy up" a certificate file — re-wrapping lines, changing whitespace, or round-tripping it through a tool that re-encodes can change the bytes and invalidate the signature. Certificates are moved, never edited.

head -1 file — if you see -----BEGIN SOMETHING-----, it is PEM. If you see binary noise, it is DER.

More precisely: xxd file | head -1. A DER certificate or key almost always starts with byte 30, the ASN.1 tag for SEQUENCE.

file cert.der also works on most systems and will say "data" for DER and "ASCII text" or "PEM certificate" for PEM.

Practical note: never trust the extension. A .crt file is PEM about as often as it is DER, and Windows tools happily produce either.

-rw------- 1 zaeem zaeem 138 Aug 20 12:55 manual.der
-rw------- 1 zaeem zaeem 138 Aug 20 12:41 ec256.der

IDENTICAL - PEM really is just Base64 around DER

4bfd2c8b6f1eec7a25b1c3a0d9f8e47256b0d3f19c8a4e26f7b53d0a1c96e482  manual.der
4bfd2c8b6f1eec7a25b1c3a0d9f8e47256b0d3f19c8a4e26f7b53d0a1c96e482  ec256.der

What to read out of this.

• You just did with grep and base64 what OpenSSL does internally. PEM genuinely is nothing more than DER wrapped in Base64 with a label. There is no magic and no extra transformation.
• The two files are byte-identical, confirmed by both cmp and matching SHA-256 hashes.
• This means you can read a certificate anywhere. Stuck on a machine with no OpenSSL? grep -v -- '-----' cert.pem | base64 -d | xxd still shows you the bytes.

💡 A safety note. This trick is fine on public things like certificates. Be careful doing it with private keys on a shared machine — the decoded key lands on disk, and if your umask is not set it may land world-readable. That is why every exercise in this track starts with umask 077.

# 1 - missing dash
Could not read private key from broken1.key
40C7B1E2A87F0000:error:1E08010C:DECODER routines::unsupported:crypto/encode_decode/decoder_lib.c:101:No supported data to decode. Input type: PEM

---
# 2 - Windows line endings
broken2.key: ASCII text, with CRLF line terminators
(no error - it loaded fine)

---
# 3 - stray leading space
Could not read private key from broken3.key
40C7B1E2A87F0000:error:1E08010C:DECODER routines::unsupported:crypto/encode_decode/decoder_lib.c:101:No supported data to decode. Input type: PEM

What to read out of this — and case 2 is the interesting one.

• Cases 1 and 3 fail with the identical message. A missing dash and a stray space produce exactly the same error, and the error names neither problem. This is why PEM troubleshooting feels like guesswork until you know what to look for.
• Case 2 did NOT fail. OpenSSL tolerates Windows CRLF line endings. But many other tools do not — Java, some load balancers, several cloud certificate importers, and older versions of nginx will reject the very same file that OpenSSL accepted happily.

🔑 That is the lesson worth carrying: "OpenSSL can read it" does not mean "everything can read it". When a certificate works locally but is rejected on upload to a cloud provider, CRLF is one of the first things to check, and the fix is one command:

sed -i 's/\r$//' cert.pem      # or:  dos2unix cert.pem

A quick way to spot all three problems at once:

cat -A broken3.key | head -3
#  ----BEGIN PRIVATE KEY-----$        <- dashes visible, $ marks the true line end
#  ^I or ^M would show tabs / carriage returns

cat -A makes invisible characters visible. It is the single most useful command for a PEM file that "looks fine".

Now imagine this at 500 hosts. Someone pastes a certificate into a ticket, a colleague copies it out of the browser, and the trailing newline is lost. It deploys to 12 servers before anyone notices that three of them silently kept the old certificate because the new file would not parse. Always validate a PEM after writing it: openssl x509 -in new.crt -noout -subject before reloading anything.

DER is the raw binary encoding. PEM is that same binary, Base64-encoded and wrapped in -----BEGIN X----- / -----END X----- lines so it can be safely copied, pasted, emailed and stored in text files.

They hold identical information — you can convert back and forth with no loss. PEM is roughly a third larger because of Base64, plus the headers and line breaks.

Practical framing: PEM is what you see almost everywhere on Linux; DER turns up in Windows and Java tooling and in some hardware appliances. Since neither the extension nor the tool's expectation is reliable, the useful habit is to check with head -1 before assuming.

A short checklist, roughly in order of how often each is the cause:

1. Line endings. CRLF from a Windows editor. OpenSSL tolerates it; many importers do not. dos2unix or sed -i 's/\r$//'.
2. Missing or extra content. A lost trailing newline, a stray space, or a lost dash from copy-paste. cat -A shows all of it.
3. Wrong object in the file. Uploading the CSR instead of the certificate, or the private key instead of the public certificate. head -1 tells you immediately.
4. Chain expectations. Many importers want the leaf certificate and the intermediates in separate fields, or in a specific order. Sending a combined bundle where a single certificate is expected fails.
5. Wrong encoding. The console wants PEM and you exported DER.

What this really demonstrates in an interview is that you treat "it works here" as evidence about your tool, not about the file.

-----BEGIN PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
-----BEGIN PRIVATE KEY-----

8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -
8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -
8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -

What to read out of this.

• All three hashes are identical. The key never changed. Only the packaging did. Converting between PKCS#1 and PKCS#8 is genuinely lossless and completely safe — it is repackaging, not re-generating.
• -nocrypt matters. Without it, openssl pkcs8 -topk8 will prompt you for a passphrase and produce an ENCRYPTED PRIVATE KEY. If a conversion suddenly starts asking for a password you did not expect, that flag is what you forgot.
• -traditional is the flag that goes the other way. On OpenSSL 3.x, openssl rsa outputs PKCS#8 by default; -traditional gives you the older PKCS#1 form. On OpenSSL 1.x the default was the opposite, which is why old blog posts and your machine sometimes disagree.

💡 The two commands to remember. They cover almost every private key format problem you will ever have:

openssl pkcs8 -topk8 -nocrypt -in any.key -out pkcs8.key    # -> BEGIN PRIVATE KEY
openssl rsa -in any.key -traditional -out pkcs1.key         # -> BEGIN RSA PRIVATE KEY

DIFFERENT FILES

    0:d=0  hl=4 l=1214 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=2 l=  13 cons: SEQUENCE
    9:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   20:d=2  hl=2 l=   0 prim: NULL
---
    0:d=0  hl=4 l=1187 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=4 l= 257 prim: INTEGER           :BB5494D4B7D52CF1C2A385F3BCE4DF...
   20:d=2  hl=2 l=   0 prim: NULL

What to read out of this — this is the parcel analogy, made visible.

• The PKCS#8 version has OBJECT :rsaEncryption near the top. That is the algorithm, written inside the file. Parcel A: self-describing. Any tool can read the first few bytes and know what it is holding.
• The PKCS#1 version goes straight to INTEGER :BB5494D4... — that is the modulus, with no algorithm named anywhere. Parcel B: the tool must already know it is RSA, because the file never says so.
• The PKCS#8 file is 27 bytes bigger. That is the cost of the label. Cheap, and worth it.

🔑 So the rule you can now derive rather than memorise: always prefer PKCS#8 (BEGIN PRIVATE KEY) when you have a choice, because it is self-describing and every modern tool accepts it. Convert to PKCS#1 only when something old specifically demands it.

BEGIN PRIVATE KEY is PKCS#8 — a generic wrapper that names the algorithm inside the file itself, so it works for RSA, EC, Ed25519 and anything else.

BEGIN RSA PRIVATE KEY is PKCS#1, the older RSA-only "traditional" format, where the algorithm is implied by the label rather than recorded in the data.

They can hold exactly the same key. Converting between them is lossless: openssl pkcs8 -topk8 -nocrypt one way, openssl rsa -traditional the other.

The reason to care: Java and several other stacks accept only PKCS#8, so a key that works perfectly in nginx can be rejected by a Java service. Recognising that as a packaging problem rather than a key problem turns a long debugging session into a one-line fix.

head -1 first — the label tells you what it really is: CERTIFICATE, PRIVATE KEY, RSA PRIVATE KEY, CERTIFICATE REQUEST or PUBLIC KEY.

Then confirm it parses as what it claims: openssl x509 -in file.pem -noout -subject -dates for a certificate, openssl pkey -in file.pem -noout -text for a key, openssl req -in file.pem -noout -subject for a CSR.

Also worth checking: grep -c BEGIN file.pem. More than one means it is a bundle — several objects concatenated in one file — and some tools want only a single object.

The habit being tested: never trust the filename, the extension, or what the person handing it to you believes it is. Thirty seconds of checking saves an outage.

=== mystery1.crt ===
mystery1.crt: ASCII text
00000000: 2d2d 2d2d 2d42 4547 494e 2050 5249 5641  -----BEGIN PRIVA
00000010: 5445 204b 4559 2d2d 2d2d 2d0a 4d49 4945  TE KEY-----.MIIE

=== mystery2.pem ===
mystery2.pem: data
00000000: 3081 8702 0100 3013 0607 2a86 48ce 3d02  0.....0...*.H.=.

=== mystery3.key ===
mystery3.key: PEM certificate
00000000: 2d2d 2d2d 2d42 4547 494e 2043 4552 5449  -----BEGIN CERTI
00000010: 5449 4649 4341 5445 2d2d 2d2d 2d0a 4d49  FICATE-----.MI

What to read out of this.

• mystery1.crt is a private key. Named .crt, contains BEGIN PRIVATE KEY. If you had uploaded that to a load balancer expecting a certificate, you would have leaked your private key into a system that logs uploads.
• mystery2.pem is binary DER. file says just data, and the bytes start with 30 — the SEQUENCE tag from Exercise B1.1. Named .pem, and it is not PEM at all.
• mystery3.key is a certificate, and file even identifies it correctly as "PEM certificate".

🔑 The 3-second identification routine, worth making automatic:

file  suspicious-file        # text or binary?
head -1 suspicious-file      # if text: what does the label say?
xxd suspicious-file | head -1  # if binary: does it start with 30? then DER

⚠️ The real danger here is not confusion, it is leakage. Mixing up a .key and a .crt in one direction is a broken deploy. In the other direction it is a private key disclosure. Always run head -1 before you upload, paste or attach anything.

Clean up the misleading files so you do not confuse yourself later:

rm -f mystery1.crt mystery2.pem mystery3.key

Only .der and .p12/.pfx carry reliable meaning. The rest are conventions, not standards, and are frequently wrong.

The two things that are real:

• Encoding: PEM (Base64 text with BEGIN/END lines) versus DER (raw binary). Determine it with head -1 or file.
• Content: certificate, private key, CSR, or a bundle of several. The PEM label states it directly; for DER you have to try parsing it.

What this question is really testing is whether you verify or assume. The answer that lands: "I never trust the extension. file plus head -1 takes three seconds and has stopped me pasting a private key into a ticket more than once."

2

-rw------- 1 zaeem zaeem 2418 Aug 20 13:22 truststore.p12
truststore.p12: data

MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Certificate bag
Bag Attributes: <No Attributes>
subject=CN=*.example.com
issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
Certificate bag
Bag Attributes: <No Attributes>
subject=C=US, O=DigiCert Inc, CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
issuer=C=US, O=DigiCert Inc, OU=DigiCert Global Root G3

What to read out of this.

• file says just data. PKCS#12 is binary, like DER. You cannot open it in an editor and see anything useful.
• "Certificate bag" appears twice. PKCS#12 organises its contents into bags — a bag for certificates, a bag for keys. Both certificates from the chain went in, and each one is listed with its subject and issuer.
• MAC: sha256 and PBKDF2, AES-256-CBC, Iteration 2048. The file really is encrypted, with the password stretched through PBKDF2 — the same idea you met in Module 01's Exercise B1.1. Note the iteration count of 2048, which is low by modern standards. That is the default, and it is why a weak .p12 password is genuinely crackable offline.
• The MAC is what detects a wrong password, which is the next exercise.

⚠️ Your issuer names, serials and dates will not match mine. example.com's certificate is renewed every few months and the CA rotates its intermediates, so the exact strings above are a snapshot, not a constant. What you should check is the shape: two certificate bags, and the first one's issuer= line equal to the second one's subject= line. Every expected output in this track that involves a live third-party site works the same way — match the structure, not the text.

💡 The other shape of the command, for when you do have a matching key and certificate — you will run this for real in Module 04:

openssl pkcs12 -export \
  -inkey server.key \          # the private key
  -in server.crt \             # its certificate
  -certfile chain.pem \        # the intermediates above it
  -name "my-server" \          # a friendly label inside the file
  -out bundle.p12

Mac verify error: invalid password?
40A7C1B2E87F0000:error:11800071:PKCS12 routines:PKCS12_item_decrypt_d2i_ex:mac verify failure:crypto/pkcs12/p12_decr.c:180:

--- now the right one ---
2

What to read out of this.

• Mac verify error: invalid password? — and notice this is a much better error than the one you got in Module 01's Exercise B1.2, where a wrong password produced bad decrypt from a padding routine.
• The reason is the MAC. PKCS#12 stores a keyed checksum over the contents. If the password is wrong, that checksum does not match, and the file can say so confidently and immediately. It does not have to decrypt garbage and hope the padding looks wrong.
• This is authenticated encryption in action — the same principle behind the AEAD cipher suites in TLS 1.3 that you saw in Exercise A2.2 of Module 01. Wrong key fails loudly, not silently.
• Unpacking gave back 2 certificates, exactly what went in. The container is lossless.

⚠️ A very common real-world stumble: when a .p12 does contain a private key, openssl pkcs12 -in bundle.p12 -out out.pem will write the key into out.pem encrypted with a new passphrase it prompts you for. If you want it unencrypted you must add -noenc (called -nodes before OpenSSL 3.0). Forgetting that flag is why so many people end up with a key their web server cannot read — which is Exercise A3.2 all over again.

A PKCS#12 file: a single password-protected binary container holding a private key, its certificate, and usually the intermediate chain. .pfx is Microsoft's name for the same thing.

You use it whenever key material has to move between systems — importing into Windows or IIS, into a Java keystore, into macOS Keychain, or uploading to a load balancer or cloud console. Most of those tools do not accept loose PEM files.

The caution worth voicing: because it has a password, people treat a .p12 as safe to email. It is not. The default PBKDF2 iteration count is low, the password is usually weak, and the file can be attacked offline at leisure. It should be handled with the same care as a bare private key, and ideally moved through a secret manager rather than a chat window.

Because PKCS#12 includes a MAC — a keyed integrity check over the contents. A wrong password produces a MAC mismatch, which is detectable directly and unambiguously.

Plain openssl enc with a CBC cipher has no such check. It decrypts with whatever key it was given, produces garbage, and only notices because the garbage does not end in valid padding — hence the unhelpful bad decrypt message.

The general principle to state: encryption without authentication cannot tell you whether decryption succeeded. That is exactly why every TLS 1.3 cipher suite is AEAD, and why modern designs never use encryption alone.

Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 2 entries

1, 20 Aug 2026, trustedCertEntry,
Certificate fingerprint (SHA-256): A4:1F:9C:82:7B:03:E5:6D:41:...
2, 20 Aug 2026, trustedCertEntry,
Certificate fingerprint (SHA-256): 7E:B2:04:D9:15:8A:6C:33:F0:...

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 148 entries

amazonrootca1 [jdk], 12 Nov 2025, trustedCertEntry,

What to read out of this.

• Java read the OpenSSL-created file without any conversion. That is the whole point of PKCS#12 being the default now — it is a genuinely shared format, and the days of converting everything to JKS are over.
• trustedCertEntry means "a certificate I trust", with no private key. A key-bearing entry would show as PrivateKeyEntry. That one word tells you whether you are looking at a keystore or a truststore.
• cacerts holds 148 entries. That is Java's own list of root CAs, completely separate from the 146 you counted in /etc/ssl/certs in Module 01's Exercise C3.1. Two different lists on the same machine.

🔑 This is the single most useful Java-TLS fact you can carry into an interview. Adding an internal root CA to the operating system with update-ca-certificates does nothing for a Java application. Java reads cacerts, not /etc/ssl/certs. The symptom is a PKIX path building failed error on a host where curl to the very same URL works perfectly.

keytool -importcert -cacerts -storepass changeit -alias my-internal-root -file myroot.crt

Now imagine this at 500 hosts. Every JVM has its own cacerts, and a JDK upgrade replaces the file — silently discarding any root you added by hand. Teams that add roots manually rediscover this every upgrade cycle. The durable fix is to bake the trust store into the container image or manage it with configuration management, never by hand on a live host.

A keystore holds your own identity — private keys with their certificates. A truststore holds certificates belonging to others that you have chosen to trust, and contains no private keys.

They are usually the same file format (PKCS#12 today, JKS historically), which is why people conflate them. The difference is purpose, and it maps to the two sides of TLS: a server presents from its keystore, and validates the other side against its truststore.

The diagnostic value: PKIX path building failed is always a truststore problem — the JVM cannot chain to a trusted root. "Alias does not exist" or "no key entry" is a keystore problem.

Because the JVM has its own trust store — $JAVA_HOME/lib/security/cacerts — completely separate from the operating system's. The internal root CA was added to the OS store with update-ca-certificates or update-ca-trust, which the JVM never reads.

Fix: keytool -importcert -cacerts -alias internal-root -file root.crt, or point the app at a custom truststore with -Djavax.net.ssl.trustStore.

The detail that shows operational experience: a JDK upgrade replaces cacerts and silently drops anything added by hand. So the durable fix is to bake it into the image or manage it with config management. And the same class of problem exists for Node.js, Python's certifi, and Firefox — every one keeps its own list.

No. PKCS#12 has been the default since Java 9, it is an open standard that OpenSSL and every other tool can read, and JKS is Oracle-proprietary with weaker protection of its contents.

Converting is one command: keytool -importkeystore -srckeystore old.jks -destkeystore new.p12 -deststoretype PKCS12.

Worth mentioning: you will still meet JKS in older systems, and keytool still reads it — it just warns you that the format is proprietary and suggests migrating.

rsa2048.key      8c4a1f92e7b530d6
r2.pem           8c4a1f92e7b530d6
r3-pkcs1.pem     8c4a1f92e7b530d6
r4-pkcs8.pem     8c4a1f92e7b530d6

What to read out of this.

• Four different files, four different encodings, one identical key. Format conversion never changes the key. It only changes how the key is written down.
• This is why conversion is safe and why you should never feel nervous doing it. You are not regenerating anything, and you cannot accidentally weaken a key by converting it.
• The check itself is the technique to remember. Deriving the public key and hashing it gives you a short, comparable fingerprint of any key file, whatever format it is in. That is exactly the tool you need for the next section.

8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -
8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -

=== now a real certificate against our key ===
b81e4f37d0a95c26e73f18b4a0d92c5e6f31870b4ac2d95e18f3b06d7c4a2e91  -
8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -

What to read out of this.

• First pair: identical. Same key, two file formats, same fingerprint. This is what a matching key and certificate look like.
• Second pair: completely different. Of course — example.com's certificate contains DigiCert-issued key material belonging to someone else entirely, and our rsa2048.key is a key we made this morning. They are not a pair, and the check says so instantly.
• Notice the commands are almost the same. openssl x509 -pubkey for a certificate, openssl pkey -pubout for a key. Both print a BEGIN PUBLIC KEY block, so both can be hashed and compared directly.

🔑 Learn this as a one-liner. You will use it more than almost anything else in this track:

diff <(openssl x509 -in server.crt -noout -pubkey) \
     <(openssl pkey -in server.key -pubout) \
  && echo "MATCH" || echo "MISMATCH"

💡 You will also see the older RSA-only version of this check in a lot of documentation. It works, but only for RSA keys — the -pubkey version above works for EC and everything else too:

openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa  -noout -modulus -in server.key | openssl md5

You will run the full matching version for real in Module 04, once you have created a certificate for a key you own.

nginx:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/server.key") failed
(SSL: error:05800074:x509 certificate routines::key values mismatch)

Apache httpd:

AH02565: Certificate and private key server.example.com:443:0 from
/etc/ssl/server.crt and /etc/ssl/server.key do not match

HAProxy:

[ALERT] unable to load SSL private key from PEM file '/etc/haproxy/server.pem'.

Java:

java.security.UnrecoverableKeyException: Cannot recover key

What to read out of this.

• nginx and Apache tell you plainly. key values mismatch and do not match are unusually clear messages by TLS standards — take the gift.
• HAProxy and Java do not. Their messages point at the file, not at the mismatch, and will send you hunting for a corrupt file or a permissions problem that does not exist.
• Whatever the wording, run the diff one-liner from D2.1 first. It takes ten seconds and rules the cause in or out before you touch anything else.

How does a mismatch happen in practice? Almost always one of these:

1. A new certificate was issued from a new CSR with a new key, and only the certificate got deployed.
2. The certificate was renewed on one server but the key came from another.
3. Two renewals ran close together and the files got crossed.
4. Someone regenerated the key "to be safe" after the CSR was already submitted.

Now imagine this at 500 hosts. The reason this is worth automating is that a mismatch is invisible until a restart — and restarts often happen hours or days later, during an unrelated deploy, at which point nobody connects the two events. A pre-deploy check that runs the diff one-liner and refuses to proceed on mismatch costs five lines and prevents a whole class of 3am incident.

Derive the public key from both and compare:

diff <(openssl x509 -in cert.crt -noout -pubkey) <(openssl pkey -in key.pem -pubout)

If they are identical, they are a pair. The older RSA-specific version compares modulus hashes with openssl x509 -noout -modulus | openssl md5 against openssl rsa -noout -modulus | openssl md5, but that only works for RSA — the -pubkey form works for EC too.

Why it works: the certificate contains the public key, and the public key can always be derived from the private key. So the public key is the shared identifier between the two files.

Where to use it: as a pre-deploy gate. A mismatch does not surface until the service restarts, which may be days after the bad deploy, so catching it at deploy time is worth the five lines.

First, confirm it with the diff check above rather than assuming — thirty seconds, no guessing.

Then find which half is wrong. The usual cause is that the certificate was issued from a different key than the one on the server: someone generated a fresh CSR (and therefore a fresh key) somewhere else, and only the resulting certificate was copied across.

Recovery: find the key that was used to create the CSR. If it still exists, deploy that key alongside the certificate. If it is genuinely lost, the certificate is useless — you must generate a new key, submit a new CSR, and reissue.

The prevention worth naming: keep the key and certificate together as a unit through the whole issuance flow, and let automation own it end to end. Every mismatch I have seen came from a manual step where the two halves travelled separately.

2

subject=CN=*.example.com
issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1

subject=C=US, O=DigiCert Inc, CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
issuer=C=US, O=DigiCert Inc, OU=DigiCert Global Root G3

-rw------- 1 zaeem zaeem 1424 Aug 20 14:10 cert-00.pem
-rw------- 1 zaeem zaeem 1180 Aug 20 14:10 cert-01.pem

cert-00.pem    subject=CN=*.example.com
cert-01.pem    subject=CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1

What to read out of this.

• grep -c 'BEGIN CERTIFICATE' is the fastest way to find out what you are holding. One means a single certificate. Two or three means a chain. It is the first thing to run when a tool complains about "too many certificates" or "expected a single certificate".
• openssl x509 -in chain.pem would only ever show you the FIRST one. This trips people up constantly — you check the dates on a bundle, see a valid certificate, and never notice that the intermediate inside it expired last week. To see them all, use the crl2pkcs7 | pkcs7 -print_certs trick above.
• Read the subject/issuer pairs as a ladder. Certificate 1's issuer is certificate 2's subject. That is the same ladder you saw in Module 01's Exercise D3.1, now in a file rather than on the wire.
• csplit splits the bundle cleanly because each certificate begins with a predictable line. Handy when a tool insists on separate files for the leaf and the chain.

🔑 The habit to build: whenever someone hands you a "certificate", run grep -c BEGIN on it before anything else. Half of all certificate-deployment problems come from a bundle being given where a single certificate was expected, or the reverse.

These are the names Let's Encrypt uses, and they have become a general convention:

• cert.pem — your certificate alone, one object.
• chain.pem — the intermediate certificate(s) above yours, without yours.
• fullchain.pem — your certificate followed by the intermediates. This is what most web servers want.
• privkey.pem — the private key, which is not a certificate at all.

nginx wants fullchain.pem in ssl_certificate. Apache historically wanted them split across SSLCertificateFile and SSLCertificateChainFile, though since 2.4.8 it accepts a combined file too.

The mistake to name: using cert.pem where fullchain.pem was needed. It works in your browser, because browsers cache intermediates they have seen before — and fails for other clients, producing unable to get local issuer certificate. That asymmetry is exactly why "it works in Chrome" is not a test.

openssl x509 -in bundle.pem -noout -text only ever reads the first object, which is a genuinely common source of missed problems — an expired intermediate hiding behind a valid leaf.

To see them all:

openssl crl2pkcs7 -nocrl -certfile bundle.pem | openssl pkcs7 -print_certs -noout

Or split first with csplit and loop over the pieces.

Why it matters operationally: intermediates expire too, and monitoring that only checks the leaf will not warn you. Any expiry check worth having walks the whole bundle.

1 & 2 — identify everything:

cd ~/tls-lab/m02/capstone

for f in a.dat b.txt c.crt d.pem e.key; do
  echo "=== $f ==="
  file "$f"
  head -1 "$f" | cat -A | cut -c1-60
done

=== a.dat ===
a.dat: data
0..$.....                                    <- binary, no BEGIN line
=== b.txt ===
b.txt: ASCII text
-----BEGIN PRIVATE KEY-----$
=== c.crt ===
c.crt: PEM certificate
-----BEGIN CERTIFICATE-----$
=== d.pem ===
d.pem: ASCII text, with CRLF line terminators
-----BEGIN RSA PRIVATE KEY-----^M$          <- ^M is the carriage return
=== e.key ===
e.key: data

a.dat is binary and starts with 30 — DER. e.key is binary but does not start with 30, and its extension says .key; try it as PKCS#12. Now confirm the key details:

openssl pkey -inform DER -in a.dat -noout -text | head -1
openssl pkey -in b.txt -noout -text | tail -2
openssl pkey -in d.pem -noout -text | head -1

Private-Key: (2048 bit, 2 primes)          <- a.dat: RSA 2048, DER
ASN1 OID: prime256v1
NIST CURVE: P-256                          <- b.txt: EC P-256, PKCS#8 PEM
Private-Key: (2048 bit, 2 primes)          <- d.pem: RSA 2048, PKCS#1, CRLF

Answer to 1 and 2: three private keys (a.dat RSA-2048 in DER, b.txt EC P-256 in PKCS#8 PEM, d.pem RSA-2048 in PKCS#1 with CRLF), one certificate (c.crt), one PKCS#12 container (e.key).

3 — normalise all three keys to unencrypted PKCS#8 PEM:

openssl pkcs8 -topk8 -nocrypt -inform DER -in a.dat  -out key1.pem
openssl pkcs8 -topk8 -nocrypt -in b.txt              -out key2.pem
openssl pkcs8 -topk8 -nocrypt -in d.pem              -out key3.pem

head -1 key1.pem key2.pem key3.pem

All three now read -----BEGIN PRIVATE KEY-----. Note that openssl pkcs8 handled the CRLF file without complaint — but the original would still have been rejected by a Java service.

4 — does any key match the certificate?

CERT_PUB=$(openssl x509 -in c.crt -noout -pubkey | sha256sum)
echo "cert : $CERT_PUB"
for k in key1.pem key2.pem key3.pem; do
  printf '%-10s ' "$k"
  openssl pkey -in "$k" -pubout | sha256sum
done

cert : b81e4f37d0a95c26e73f18b4a0d92c5e6f31870b4ac2d95e18f3b06d7c4a2e91  -
key1.pem   3f9a2c8e5b1d47f0a6c39e82b74d105fc8e3a19b6d24f870e5c1a93b47d6082e  -
key2.pem   d3e0917b45ca28f6013b7e9d5a8c46e2f70b91d3c85a24e6f7b53d0a1c96e482  -
key3.pem   8c4a1f92e7b530d6a8c19f4e73b02d5a6f81c93b47e0d258a1f6b3c9e074d582  -

No match, and that is the correct answer. c.crt is example.com's real certificate — its private key lives on that site's infrastructure, not in this folder. None of the three fingerprints comes close.

A second, faster argument worth putting in the report: compare the key types before you even hash anything.

openssl x509 -in c.crt -noout -text | grep -A1 'Public Key Algorithm'
for k in key1.pem key2.pem key3.pem; do printf '%-10s ' "$k"; openssl pkey -in "$k" -noout -text | head -1; done

If the certificate holds an EC key and a candidate is RSA, they cannot possibly be a pair and there is no need to compare fingerprints at all. Ruling candidates out cheaply before doing the expensive check is a good habit generally.

This is the trap. The instinct is to keep converting until something matches. Nothing will. Recognising that the answer is legitimately "none of them" — and being able to prove it rather than just failing to find a match — is the point of requirement 4.

5 — find and fix the CRLF file:

file *.pem *.crt *.txt 2>/dev/null | grep CRLF
sed -i 's/\r$//' d.pem
file d.pem

d.pem: ASCII text, with CRLF line terminators
d.pem: ASCII text

6 — list the container without extracting:

openssl pkcs12 -info -in e.key -passin pass:changeit -nokeys -noout

-noout is what keeps it off disk. Two Certificate bag entries appear, no private key — so e.key is a truststore, despite being named .key. Worth flagging in the report: a file named .key that contains no key at all is exactly the kind of thing that causes an outage when somebody assumes.

The three things this capstone is really teaching:

1. Identify before you act. Every one of the six answers came from file and head -1 before any conversion was attempted.
2. Converting is safe; assuming is not. Format conversion never damages a key, so there is no risk in normalising early. The risk is entirely in guessing what a file is.
3. "No match" is a valid, provable answer. Being able to demonstrate that a key and a certificate are not a pair is just as operationally useful as showing that they are.

-nokeys             Don't output private keys
-nocerts            Don't output certificates
-clcerts            Only output client certificates
-cacerts            Only output CA certificates
-noenc              Don't encrypt private keys
-nodes              Don't encrypt private keys; deprecated

What to read out of this.

• The flags are all negative, which is genuinely confusing until you see them listed together. You do not say "give me the key" — you say "don't give me the certificates". So the answer is -nocerts -noenc.
• -nodes is listed as deprecated, with -noenc as the replacement. Almost every blog post and Stack Overflow answer still says -nodes. It still works, but knowing the current name is a small signal that you read the docs rather than the first search result.
• -clcerts versus -cacerts is how you separate the leaf certificate from the intermediates when unpacking a bundle.

So the full command is:

openssl pkcs12 -in bundle.p12 -nocerts -noenc -out server.key

⚠️ And immediately after running it: chmod 600 server.key. OpenSSL does not set restrictive permissions on files it extracts from a .p12, so the key can land world-readable if your umask is loose. This is a real and commonly missed step.

DER is the raw binary encoding. PEM is that same binary, Base64-encoded and wrapped in -----BEGIN X----- / -----END X----- lines so it survives copy-paste and email.

Identical information, no loss either way. PEM is about a third larger. Tell them apart with head -1, or xxd | head -1 — DER almost always starts with byte 30.

PKCS#8 versus PKCS#1. PKCS#8 is self-describing (the algorithm is named inside the file) and works for any key type; PKCS#1 is RSA-only with the type implied by the label.

It matters because Java and several other stacks accept only PKCS#8. Conversion is lossless: openssl pkcs8 -topk8 -nocrypt one way, openssl rsa -traditional the other.

No — it is roughly equivalent to RSA-3072, so slightly stronger. The bit counts measure different things and cannot be compared across families.

EC is also much smaller on the wire and cheaper to sign with, which is why it is the modern default for web servers.

Derive the public key from both and compare:

diff <(openssl x509 -in c.crt -noout -pubkey) <(openssl pkey -in k.pem -pubout)

It works because the certificate contains the public key, and the public key can always be derived from the private key. Run it as a pre-deploy gate — a mismatch is otherwise invisible until a restart.

A private key, its certificate, and usually the chain, in one password-protected binary container. .pfx is the same thing under Microsoft's name.

Handle it exactly like a bare private key. The default PBKDF2 iteration count is low and the password is usually weak, so it is crackable offline. Never email one.

PKCS#12 includes a MAC — a keyed integrity check. A wrong password fails the MAC immediately and unambiguously.

Plain CBC encryption has no such check; it decrypts to garbage and only notices via a padding error. That is the difference between authenticated and unauthenticated encryption, and it is why every TLS 1.3 suite is AEAD.

Usually no. The server must start unattended, so the passphrase ends up somewhere the machine can read — typically a file next to the key, protecting nothing while adding an outage risk.

The real answers to key protection are KMS or HSM-backed keys, disk encryption, 0600 permissions and short certificate lifetimes. A passphrase is right for CA root keys and developer laptops, where a human is present anyway.

The JVM's own trust store, cacerts, does not contain the internal root — the root was added to the OS store, which Java never reads.

Fix with keytool -importcert -cacerts, or a custom truststore. And bake it into the image, because a JDK upgrade replaces cacerts and silently drops manual additions.

head -1 for the label, and grep -c 'BEGIN CERTIFICATE' for the count. The first tells you it is actually a certificate and not a key or a CSR; the second tells you whether it is a single certificate or a bundle.

Then openssl x509 -noout -subject -dates to confirm it parses and is current. Never trust the extension or the person's description.

Because a signature covers the exact bytes. Re-wrapping lines, changing whitespace, or letting an editor rewrite line endings changes those bytes, and the signature no longer verifies.

Certificates are copied whole and replaced whole. If a file needs changing, regenerate or re-download it.

-text gives a friendly interpretation, and only works if the file parses as the expected object type. asn1parse shows the raw nested structure — tags, lengths, offsets — regardless of what the object is supposed to be.

So it is the tool for a file that will not load: it tells you whether the internal structure is intact and you have the wrong command, or genuinely corrupt.

Question selection was cross-referenced against publicly published 2026 SSL/TLS, OpenSSL and Java keystore interview question sets, then rewritten and deepened:

• InterviewPrep — Top 25 SSL Certificate Interview Questions and Answers
• JavaInUse — Top OpenSSL Interview Questions (2026)
• ClimbTheLadder — 10 SSL Certificate Interview Questions and Answers
• ClimbTheLadder — 15 PKI Interview Questions and Answers
• Javarevisited — Can you answer interview questions on Truststore and Keystore?
• Devinterview.io — Web Security interview questions for 2026