Bernd RodlerandClaude Opus 5
759ab7fe8c
Manifests and a runbook for the internal CA that issues 1-year S/MIME certificates. Per the agreed split: these are applied by hand, and the root-key ceremony in section 3 is deliberately NOT automated - the whole value of an offline root is that its private key never exists on a machine that runs services or tooling. Structural recommendation up front (section 0), because it decides whether promoting to vncmail later is a config change or a re-rooting: name the root for the ORGANISATION, not the environment. One root, generated once at prod grade, with per-environment intermediates under it. Promotion is then "issue a second intermediate from the same root" - a one-hour ceremony - and the trust anchor already distributed to laptops, phones and partners does not change. A throwaway "VNC Sandbox Root" instead means redistributing a new anchor to every device and every external party who ever verified a signature. That cost is invisible today and expensive later. Security shape of the deployment: - Own namespace (vnc-ca), NOT vncmail. The webmail pod is internet-facing; the CA signs certificates. A compromise of the former must not be a compromise of the latter. - Port 8080 (CRL + OCSP) is the ONLY thing the public ingress routes, and only two path prefixes. Not the admin web, not the REST API, not the public enrolment pages. - Port 8443 (admin + REST, client-cert authenticated) is never exposed through an ingress - cluster-internal or kubectl port-forward only, enforced by NetworkPolicy as defence in depth. - The RA credential the enrolment route uses gets its own EJBCA role limited to issue/revoke under one profile. It lives on an internet-facing pod, so its blast radius should be "mint an S/MIME cert" and not "reconfigure the CA". Two things the runbook makes you prove rather than assume: - The NetworkPolicy actually enforces. Applying one on a CNI that does not implement it succeeds silently and protects nothing, so section 6 has a probe that MUST time out - a 401 means the REST API is exposed cluster-wide. - The CA backup restores. ejbca-db-data holds the intermediate private key and, with key recovery on, escrowed user decryption keys; an untested CA backup is a belief. Section 7 surfaces a decision rather than making it silently. S/MIME is unlike TLS in that losing a private key makes every message ever encrypted to that user permanently unreadable - re-issuing does not help, the old mail was encrypted to the old key. So key escrow is on by default here, which is the defensible choice when mail is a business record, but it means the CA operator can decrypt user mail. That is worth deciding consciously and being able to explain, not discovering. MariaDB rather than the container's embedded H2 deliberately: H2 is not supported for data you intend to keep, and the database is the one component that must not need re-platforming on promotion. Image tag pinned. The env-var contract is the part most likely to have drifted between EJBCA releases, so the runbook says to verify it against the tag pulled rather than trusting these values, and gives the log grep that shows the failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
52 lines
2.0 KiB
YAML
52 lines
2.0 KiB
YAML
# PUBLIC surface of the CA — revocation checking ONLY.
|
|
#
|
|
# Two prefixes are routed and nothing else. Not the admin web, not the REST API,
|
|
# not the public enrolment pages (/ejbca/ra/, /ejbca/enrol/). Anything else at
|
|
# this host 404s because no rule matches it.
|
|
#
|
|
# WHY THIS MUST BE PUBLIC AT ALL: every certificate this CA issues carries the
|
|
# CRL Distribution Point and OCSP responder URL *inside* it, and those URLs are
|
|
# fetched by whoever is validating the certificate. For internal-only S/MIME that
|
|
# could stay private — but the moment a signed message leaves the building, the
|
|
# recipient's mail client resolves these URLs from the outside. They also become
|
|
# permanent: certificates already issued keep pointing here for their full year,
|
|
# so this hostname cannot be changed casually. Fix the hostname before the first
|
|
# real issuance, not after.
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
name: vnc-ca-public
|
|
namespace: vnc-ca
|
|
annotations:
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
# Revocation data is public by design and must be cacheable — an OCSP
|
|
# responder that is slow or down makes every client either hang or
|
|
# soft-fail open, and soft-fail-open is the same as no revocation at all.
|
|
nginx.ingress.kubernetes.io/proxy-read-timeout: "20"
|
|
spec:
|
|
ingressClassName: public
|
|
tls:
|
|
- hosts:
|
|
- ca.sandbox.vnc.de
|
|
secretName: vnc-ca-public-tls
|
|
rules:
|
|
- host: ca.sandbox.vnc.de
|
|
http:
|
|
paths:
|
|
# CRL download — http://ca.sandbox.vnc.de/ejbca/publicweb/crls/...
|
|
- path: /ejbca/publicweb/crls
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: ejbca
|
|
port:
|
|
number: 8080
|
|
# OCSP responder — POST target for status queries.
|
|
- path: /ejbca/publicweb/status/ocsp
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: ejbca
|
|
port:
|
|
number: 8080
|