DevOps Foundations · Module 2: Networking, DNS, HTTP and TLS · Lab
Inspect TLS Failures with a Test CA and Fixture Certificates
50 min hands-on · Advanced
Local Linux shell with openssl; a self-made test CA directory under /tmp/dlab-m02-03. No public domain, no real CA, no production endpoints.
Two ways to do this lab: in your browser on Killercoda (free, no install), or on your own machine as a local guide. Killercoda runs one free scenario at a time: if you see a waiting queue, close other Killercoda tabs and wait a minute.
Objectives
- Create a test CA and issue fixture certificates with one deliberate flaw each
- Diagnose an expired certificate, a wrong hostname and a missing intermediate from the command line
- Verify with explicit trust instead of disabling verification
Step 1
Build the CA and the flawed fixtures
Generate a test CA, then issue three server certificates: one expired (short -days with backdated start, or an already-lapsed fixture), one with a SAN for the wrong name, and one correct leaf whose chain file omits the intermediate. Keep the CA certificate separate and labeled TEST ONLY.
Step 2
Diagnose each flaw
Serve each fixture with openssl s_server on a different local port and run s_client with -CAfile pointing at the test CA. Record the verify return code and the line that names the flaw for all three cases.
Step 3
Show the right repair per case
State the correct production repair for each: reissue with valid dates, reissue with the correct SAN, serve the full chain. Confirm the corrected fixture verifies with return code 0. Never use -verify_return_error bypasses or --insecure equivalents.
How to confirm it worked
- All three flaws diagnosed with quoted verify codes
- Trust is always explicit (-CAfile); verification is never disabled
- Each case ends with the named production repair, not a workaround
- The test CA directory is labeled TEST ONLY and stays under /tmp