Files
bcs-website/k8s/ingress.yaml
T
bmr_bluecap 6f802826df k8s: pre-issue the production TLS cert for the internal hop
Public traffic terminates TLS at the Pangolin VPS, which then proxies to the
control-plane nodes over https:443 — the pattern every other k3s-backed
Pangolin resource follows — so the cluster needs its own valid certificate for
the production hostnames, not just the staging one.

Add www.bluecapstrategies.com and bluecapstrategies.com to the tls block as
bluecap-website-tls. Safe to do before cutover, and deliberately done now:
letsencrypt-prod solves DNS-01 through Cloudflare, so issuance only needs a
temporary TXT record in the zone. No A record has to point at the cluster and
the live WordPress site is untouched. The Cloudflare token was extended to
cover the zone on 2026-10-09.

Both hostnames are listed because the canonical-host decision is still open;
holding a cert for each keeps either choice available, and the redirect is
configured separately.

Pangolin's edge certificate is HTTP-01 and cannot be pre-issued this way; it
is obtained on the first HTTPS request after DNS moves.
2026-10-09 08:05:19 -04:00

79 lines
3.3 KiB
YAML

# Two audiences, deliberately separated:
#
# 1. bcs.int.7tl-homelab.com — STAGING. LAN-only (*.int resolves to the internal traefik LB at
# 10.66.15.30) with a real Let's Encrypt cert. This is how the rebuild is reviewed before
# launch. Safe: it is not reachable from the internet and does not touch the real domain.
#
# 2. www.bluecapstrategies.com / bluecapstrategies.com — PRODUCTION. Listed as routes so the
# cluster is ready, but deliberately NOT in the tls block yet: the live WordPress site still
# serves these names and must keep doing so until cutover. Requesting a cert for them is a
# launch step, not a prerequisite.
#
# TLS: ClusterIssuer is `letsencrypt-prod` (NOTE: not "letsencrypt-production" — an earlier comment
# here had the name wrong). It solves via DNS-01 against Cloudflare, which means a cert can be
# issued BEFORE any DNS points at this cluster. At cutover, add the two production hosts to the
# tls block and let the cert issue first, then move DNS — no insecure window, no HTTP-01
# chicken-and-egg. That requires bluecapstrategies.com to be in the Cloudflare account the
# cert-manager API token can reach; verify that before relying on it.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: bluecap-website
namespace: bluecap-strategies
annotations:
traefik.ingress.kubernetes.io/router.entrypoints: websecure
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- bcs.int.7tl-homelab.com
secretName: bcs-int-tls
# Production hostnames. This is the INTERNAL hop only: public traffic terminates TLS at the
# Pangolin VPS, which then proxies to these nodes over https:443 (the pattern every other
# k3s-backed Pangolin resource uses), so the cluster needs its own valid cert for these names.
#
# Safe to issue before cutover and deliberately done so: letsencrypt-prod solves DNS-01 via
# Cloudflare, which only needs a temporary TXT record in the zone — no A record has to point
# here, and the live WordPress site is unaffected. Pangolin's own edge cert is HTTP-01 and
# CANNOT be pre-issued; it is obtained on the first request after DNS moves. See
# docs/launch-checklist.md section 1.1.
#
# Both names are listed because the canonical-host decision (section 1.6) is still open;
# holding a cert for each keeps either choice available. The redirect is configured
# separately and does not depend on this.
- hosts:
- www.bluecapstrategies.com
- bluecapstrategies.com
secretName: bluecap-website-tls
rules:
- host: bcs.int.7tl-homelab.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: bluecap-website
port:
name: http
- host: www.bluecapstrategies.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: bluecap-website
port:
name: http
- host: bluecapstrategies.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: bluecap-website
port:
name: http