Week 5, Day 3 — PKI & Certificate Authority

PKI trust chains, the strongswan-pki toolkit, and certificate lifecycle

Part 1 — PKI trust model (10 min)

• A Public Key Infrastructure is a system for creating and managing digital certificates — cryptographic credentials that bind a public key to an identity. The trust chain:
  Root CA: Self-signed. Trusted because we explicitly install its certificate as trusted. In our lab, we create our own root CA on S3. In production, this would be a commercially trusted CA (DigiCert, Let's Encrypt) or an internal enterprise CA.
  End-entity certificates: Signed by the root CA. Anyone who trusts the root CA automatically trusts all certs it signed. S1 and S3 each get their own certificate issued by our root CA.
• Why S3 is the CA in our lab: the CA key must be protected carefully. In production it would be on a hardware security module, disconnected from the network. In our lab, S3 is the "secure" server that doesn't run other public-facing services — a reasonable analogy. In practice, the CA could be on any machine; this is a pedagogical choice.
• The files involved:
  /etc/ipsec.d/private/caKey.pem — CA's private key. Never leaves S3. chmod 600.
  /etc/ipsec.d/cacerts/caCert.pem — CA's public certificate. Distributed to all clients that need to trust this CA.
  /etc/ipsec.d/private/s1Key.pem — S1's private key. Never leaves the machine it was generated for.
  /etc/ipsec.d/certs/s1Cert.pem — S1's certificate, signed by the CA. Shared with peers.

Part 2 — strongswan-pki command syntax (12 min)

• The ipsec pki command is the Swiss Army knife for certificate operations. Walk through each command used in today's lab:
  ipsec pki --gen --type rsa --size 4096 --outform pem > file.pem — generate a new RSA private key, output as PEM format, write to file.
  ipsec pki --self --ca --lifetime 3650 --in caKey.pem --type rsa --dn "CN=..." --outform pem > caCert.pem — create a self-signed CA certificate. --ca marks it as a CA (allowed to sign other certs). --lifetime 3650 = 10 years.
  ipsec pki --print --in certfile.pem — inspect a certificate's contents: issuer, subject, validity dates, key size, flags.
  The pipeline for server cert generation: ipsec pki --pub --in privateKey.pem | ipsec pki --issue --lifetime 730 --cacert caCert.pem --cakey caKey.pem --dn "..." --san hostname --flag serverAuth --flag ikeIntermediate --outform pem > cert.pem
• Important flags in the server cert issuance command:
  --san s1.yourname.net — Subject Alternative Name. This is the hostname the cert is valid for — must match what the remote peer will present as its identity in ipsec.conf.
  --flag serverAuth — marks the cert as valid for server authentication (TLS/IPSec).
  --flag ikeIntermediate — required by some IKE implementations (including older StrongSwan) to accept the cert for IKE authentication.
  --lifetime 730 — two years in days.
• The copy-paste error in the original notes: The server cert issuance command must use --cakey /etc/ipsec.d/private/caKey.pem (the CA's private key to sign the cert), not the server's own key. The notes had a transcription error using s3Key.pem as the CA key — this would fail because s3Key.pem is not the CA key. Always use caKey.pem as the --cakey argument.

Part 3 — Distinguished Names (8 min)

• The Distinguished Name (DN) is the identifier embedded in a certificate. It uses a hierarchical format with attributes separated by commas:
  C=CA — Country (ISO 3166-1 alpha-2 code)
  O=YourName — Organisation
  CN=YourName.net — Common Name (for a CA cert, this is the CA's name; for a server cert, this is the hostname)
• The DN in the server certificate's leftid/rightid in ipsec.conf must match exactly what was embedded in the certificate during issuance. A mismatch causes authentication failure even if the certificate is technically valid.