← Week 5: PKI Architecture + Rust Integration

Day 34: Final Challenge — TLS Inspector CLI

Phase 1 · June 16, 2026 · Phase 1 Complete

← Week 5: PKI Architecture + Rust Integration

Agenda (3 hours)

  • Review (30 min): Phase 1 concepts from memory — no notes
  • Build (150 min): tls-inspect — portfolio-worthy CLI tool
  • Reflect (30 min): What do you know now that you didn't on May 14?
← Week 5: PKI Architecture + Rust Integration

Phase 1 Final Concepts Check

Answer from memory:

  1. Explain the TLS 1.3 key schedule from DHE shared secret to application traffic keys.
  2. What is the difference between AKI and SKI, and how do they link a cert chain?
  3. What is pathLenConstraint and why does it matter in a multi-tenant PKI?
  4. What does CT prevent, and what does an SCT prove?
  5. Why is OCSP stapling better than traditional OCSP from both privacy and performance perspectives?
  6. What is the minimum set of extensions for a CA certificate vs a TLS leaf cert?
← Week 5: PKI Architecture + Rust Integration

Final Challenge: tls-inspect

Build a production-quality Rust CLI: tls-inspect <hostname> [--port N] [--json]

Required features:

  1. TLS handshake info: version, cipher suite, negotiated ALPN
  2. Certificate chain: for each cert in the chain:
    • Subject DN, Issuer DN
    • Serial number (hex)
    • Validity period + days until expiry (or "EXPIRED: N days ago")
    • SANs
    • BasicConstraints: cA flag, pathLen
    • KeyUsage bits (human-readable)
    • ExtendedKeyUsage OIDs (human-readable)
    • AKI/SKI linkage verified ✓/✗
  3. OCSP check: if a stapled OCSP response is present, parse and report status
  4. CT check: if SCTs are embedded in the cert, count them and report log IDs
← Week 5: PKI Architecture + Rust Integration

Required Crates

[dependencies]
tokio = { version = "1", features = ["full"] }
rustls = "0.23"
tokio-rustls = "0.26"
webpki-roots = "0.26"
x509-parser = "0.16"
rustls-pki-types = "1"
clap = { version = "4", features = ["derive"] }
serde_json = "1"  # for --json output
chrono = "0.4"    # for date formatting
← Week 5: PKI Architecture + Rust Integration

Output Format (text mode)

tls-inspect google.com

Host:        google.com:443
TLS Version: TLSv1.3
Cipher:      TLS_AES_256_GCM_SHA384
ALPN:        h2

Certificate Chain (3 certs):

[0] LEAF
  Subject:    CN=*.google.com
  Issuer:     CN=GTS CA 1C3, O=Google Trust Services LLC, C=US
  Serial:     0A:1B:2C:...
  Valid:      2026-04-01 → 2026-06-24 (42 days remaining)
  SANs:       *.google.com, google.com
  KeyUsage:   digitalSignature
  EKU:        serverAuth
  AKI/SKI:    ✓ linked

[1] INTERMEDIATE ...
[2] ROOT ...

OCSP: good (thisUpdate: 2026-05-13, nextUpdate: 2026-05-20)
CT:   2 SCTs embedded (Google 'Argon2026h1', Cloudflare 'Nimbus2026h1')
← Week 5: PKI Architecture + Rust Integration

Stretch Goals

  • --no-verify: skip chain validation (show certs even if expired/untrusted)
  • Check against a custom CA file: --ca-file ca.pem
  • Show certificate fingerprint (SHA-256)
  • Flag certs with weak keys (RSA < 2048, EC < 256)
  • --check-crl: fetch and check CRL (uses code from Day 27)
← Week 5: PKI Architecture + Rust Integration

Phase 1 Reflection

Write a 1-page summary:

  1. What was the most surprising thing you learned?
  2. Which topic do you feel you need to revisit before Phase 2?
  3. How does what you learned change your mental model of your team's provisioning service?

This reflection feeds directly into your Phase 7 write-up.

← Week 5: PKI Architecture + Rust Integration

Resources

  • All crates and RFCs from Phase 1
  • The Day 7 tool you built is a simpler version — extend it
  • clap derive API for CLI argument parsing
  • Your cert_debugging_runbook.md for reference on error cases