Stéphane Tailland
26aa89643c
LibreChat served the lab CA's own certificate as its server certificate — a CA:TRUE certificate valid for the whole *.sttlab.local wildcard, from a hand-made tls.yaml that also carried the CA's private key. Gitignored, so never leaked, but the only service in the estate still copying the CA around instead of being issued a leaf. Now a cert-manager Certificate for librechat.sttlab.local: CA:FALSE, one dnsNames, key generated in the cluster and rotated there. The two uses of that Secret had to be separated first, which is the part worth knowing: sttlab-tls was both the ingress certificate and the CA bundle mounted as NODE_EXTRA_CA_CERTS for outbound calls. Replacing it with a leaf alone would have left LibreChat unable to verify Keycloak. The CA certificate now comes from ca-configmap.yaml — the certificate, never the key, committed like the agents'. Verified: the ingress serves CA:FALSE with SAN librechat.sttlab.local, the pod's outbound call to Keycloak returns 200 with TLS verified, and the old secret is deleted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
22 lines
714 B
YAML
22 lines
714 B
YAML
# cert-manager issues this into the `librechat-tls` Secret.
|
|
#
|
|
# It replaces a hand-made `tls.yaml` that carried the lab CA's own certificate
|
|
# and private key, which LibreChat then served as its server certificate — a
|
|
# CA:TRUE certificate valid for the whole `*.sttlab.local` wildcard, where a
|
|
# leaf for one name is what a server needs.
|
|
#
|
|
# The key is generated in the cluster, rotated by cert-manager, and never
|
|
# reaches a file anyone has to remember not to commit.
|
|
apiVersion: cert-manager.io/v1
|
|
kind: Certificate
|
|
metadata:
|
|
name: librechat-tls
|
|
namespace: librechat
|
|
spec:
|
|
secretName: librechat-tls
|
|
dnsNames:
|
|
- librechat.sttlab.local
|
|
issuerRef:
|
|
name: sttlab-local-ca
|
|
kind: ClusterIssuer
|