# Pathrule Pattern: TLS Certificates and HTTPS Operations (1.0.0) # ::pathrule:package:tls-https-operations ### [RULE] Issue certificates for the exact service identities (path: /infra/tls) A valid certificate is valid only for its encoded identities and trust chain. DNS aliases, internal names, load-balancer endpoints, and service-mesh identities need an intentional mapping rather than assumptions based on the common name. - Declare every public hostname the endpoint serves and remove retired names through a staged traffic and certificate change rather than silently relying on an old SAN. - Use a challenge method compatible with the real ingress and DNS ownership; test that redirects, proxies, firewalls, and split-horizon records do not intercept validation. - Use wildcards only when the DNS credential and issuance scope match the blast radius, and remember that a wildcard does not automatically cover the zone apex. - For internal mTLS, define workload identities and trust domains separately from public DNS names instead of using one broad certificate for every service. See /deploy for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Serve the complete chain and verify it from outside (path: /deploy) A server can appear healthy in one browser because that client cached an intermediate while clean clients fail to build the chain. The deployed artifact must be self-sufficient for supported trust stores. - Configure the service with the leaf certificate followed by the required intermediate certificates in issuer order. - Do not serve a private root as if it were an intermediate; distribute internal trust anchors through the client trust-management channel. - Probe the public endpoint from outside the cluster or load balancer and inspect negotiated protocol, presented chain, hostname validation, and expiry. - Test representative older and automated clients where compatibility matters; browser success alone does not prove command-line, mobile, or embedded trust behavior. See /ops/runbooks for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Limit private-key access and make replacement routine (path: /infra/tls) The certificate is public; the private key is the service's identity. A copied or over-readable key lets an attacker impersonate the endpoint until trust is removed, even if the certificate file itself is rotated. - Generate keys through the approved secret, key-management, or workload-identity system and grant read or signing access only to the terminating service. - Use separate keys for environments and independent services so one compromise does not require a fleet-wide emergency replacement. - Do not place keys in images, repositories, logs, support bundles, or general environment dumps; mount or retrieve them through the platform's protected mechanism. - Practice replacement with overlapping certificate validity and reload support, then revoke or remove the prior key after all terminating instances have changed. See /deploy for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Redirect to HTTPS without breaking bootstrap and recovery (path: /deploy) A blanket redirect can loop behind a proxy, hide a failed challenge endpoint, or make recovery harder after strict transport policy reaches clients. Redirect and header policy must follow verified request provenance and deployment order. - Determine the original scheme from a trusted proxy contract, not an arbitrary public header, before redirecting HTTP to the canonical HTTPS origin. - Exclude or correctly route the certificate challenge path required by the active issuance method and test renewal through the production edge. - Introduce strict transport policy only after every covered hostname works on HTTPS and the organization accepts the persistence and subdomain consequences. - Keep health and internal administration routes aligned with the intended transport boundary; do not leave a privileged plaintext bypass because it is convenient inside the network. See /infra/tls for the adjacent decision or procedure that completes this constraint. --- ### [MEMORY] Certificate renewal is an observed deployment loop (path: /ops/runbooks) Obtaining a renewed certificate is not success if the load balancer, proxy, secret mount, or long-running process still serves the old one. The lifecycle ends only when every public endpoint presents the replacement. - Track certificate expiry from the outside and alert with enough lead time for failed issuance, approval, distribution, and rollback. - After renewal, reload or roll terminating services through a bounded deployment and query each endpoint or region for the served serial and expiry. - Monitor issuance and activation failures separately; one proves authority could not mint a certificate, the other proves the workload did not adopt it. - Retain renewal logs and ownership without retaining private-key material so operators can distinguish DNS, rate, permission, and deployment failures. See /infra/tls for the rule or workflow that puts this decision into practice. --- ### [MEMORY] mTLS authenticates a workload, not an authorization decision (path: /infra/tls) A trusted client certificate proves possession of a key under an accepted authority. It does not by itself decide which tenant, method, topic, or resource the workload may access. - Validate client chain, validity, intended usage, and workload identity at the endpoint; reject ambiguous fallback to unauthenticated transport. - Map the verified identity to a service principal and apply authorization at the application or gateway operation boundary. - Plan client and server trust-bundle rotation with overlapping roots or intermediates so both sides can move without a synchronized outage. - Record peer identity and authorization outcome in structured audit signals without logging certificate private material or unnecessary subject data. See /deploy for the rule or workflow that puts this decision into practice. --- ### [SKILL] rotate-tls-certificate (path: /) --- name: rotate-tls-certificate description: Rotate a public or internal TLS certificate, private key, intermediate, or trust bundle. --- # Rotate Tls Certificate Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result. 1. Inventory every terminating endpoint, identity, issuer, secret location, reload mechanism, client trust dependency, and owner affected by the rotation. 2. Issue the replacement through the approved authority and validate names, usage, chain, key access, and challenge or enrollment evidence before distribution. 3. Stage new certificate and trust material with overlap, then reload or roll a small target while retaining the prior credential for rollback. 4. Probe handshake, chain, hostname, client authentication, protocol, and application health from representative networks and clients. 5. Complete rollout, confirm every target presents the replacement, retire the prior key and certificate according to policy, and update expiry monitoring to the new identity. ## Exit criteria The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.