Working with Certificate-Based Authentication
1. Understanding Public Key Infrastructure
| Component | Role |
|---|
| CA (Certificate Authority) | Issues and signs certificates |
| RA (Registration Authority) | Validates requestor identity |
| Subscriber | Holder of the certificate |
| Relying Party | Verifies certificates |
| CRL / OCSP | Revocation distribution |
| Trust anchor | Root CA in trust store |
2. Using X.509 Digital Certificates
| Field | Purpose |
|---|
| Subject | Identity (CN, O, OU) |
| Issuer | Signing CA |
| Serial Number | Unique per CA |
| Validity | NotBefore / NotAfter |
| Public Key | RSA / ECDSA / EdDSA |
| SAN | Subject Alternative Names (DNS, IP, URI) |
| EKU | Extended Key Usage (clientAuth, serverAuth) |
| Signature | CA's signature over TBSCertificate |
3. Implementing Client Certificate Authentication
Example: Nginx client cert
server {
listen 443 ssl;
ssl_certificate server.crt;
ssl_certificate_key server.key;
ssl_client_certificate ca-bundle.crt;
ssl_verify_client on;
ssl_verify_depth 2;
location /api {
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_pass http://upstream;
}
}
4. Implementing Mutual TLS (mTLS)
Client ─── ClientHello ──→ Server
Client ←── ServerHello + Cert + CertReq ── Server
Client ─── ClientCert + ClientKeyExchange + CertVerify ──→ Server
Both ←── Finished ──→
| Use Case | Pattern |
|---|
| Service mesh | Istio, Linkerd auto-issue per-pod certs |
| B2B API | Partner-issued client certs |
| IoT | Device identity cert per unit |
| FAPI banking | mTLS-bound OAuth tokens |
5. Generating Certificate Signing Requests
Example: OpenSSL CSR
openssl ecparam -name prime256v1 -genkey -out client.key
openssl req -new -key client.key -out client.csr \
-subj "/CN=alice@acme.com/O=Acme/C=US" \
-addext "subjectAltName=DNS:alice.acme.com,email:alice@acme.com" \
-addext "extendedKeyUsage=clientAuth"
6. Validating Certificate Chains
| Check | Detail |
|---|
| Chain build | Cert → Intermediate(s) → Root in trust store |
| Signature | Each cert signed by parent's private key |
| Validity dates | All certs within NotBefore/NotAfter |
| Path length | Basic Constraints respected |
| Name constraints | SAN matches expected name |
| EKU | clientAuth present |
| Revocation | CRL or OCSP not revoked |
7. Checking Certificate Revocation
| Method | Detail |
|---|
| CRL | Periodic blob of revoked serials — large, stale |
| OCSP | Per-cert query to responder — privacy issue |
| OCSP Stapling | Server attaches signed status — preferred |
| CRLite / CRLSets | Browser-pushed compressed lists |
| Short-lived certs | Rotation < revocation window (no CRL needed) |
8. Setting Certificate Expiration
| Cert Type | Lifetime (2026) |
|---|
| Public TLS | ≤398 days (CA/B Forum), trending to 90 days |
| Internal mTLS | 1–24 hours (SPIFFE) |
| Code signing | 1–3 years |
| Root CA | 10–25 years |
9. Implementing Certificate Pinning
Example: OkHttp pinning
CertificatePinner pinner = new CertificatePinner.Builder()
.add("api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") // backup
.build();
new OkHttpClient.Builder().certificatePinner(pinner).build();
Warning: Pinning without a backup pin can brick the app if the cert rotates. Always pin to public key (SPKI) and include a backup.
10. Using Smart Cards for Authentication
| Standard | Use |
|---|
| PIV (FIPS 201) | US Federal CAC/PIV cards |
| PKCS#11 | Cross-platform crypto token API |
| PKCS#15 | On-card data structure |
| CCID | USB smart-card reader protocol |
| Auth | PIN unlocks private key → signs challenge |