TLS Certificates and HTTPS Operations
Pathrule4 Rules • 2 Memories • 1 Skill
HTTPS failures are lifecycle failures as often as cryptographic failures: the certificate covers the wrong names, an intermediate is missing, renewal cannot complete from the real ingress, a private key is copied too broadly, or clients pin assumptions the operator cannot rotate. This pattern constrains certificate identity, key access, protocol policy, and redirect behavior; it records automated renewal and internal trust decisions and supplies issue and rotation runbooks. It complements DNS and secrets patterns but focuses on transport identity, certificate chains, handshake compatibility, mTLS, renewal challenges, and staged key replacement.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
Rules
4Issue certificates for the exact service identities/infra/tlshighstrictList canonical names and service identities explicitly, prove control through the chosen challenge path, and avoid wildcard convenience without an ownership model.
| 1 | 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. |
| 2 | |
| 3 | - 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. |
| 4 | - 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. |
| 5 | - 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. |
| 6 | - For internal mTLS, define workload identities and trust domains separately from public DNS names instead of using one broad certificate for every service. |
| 7 | |
| 8 | See /deploy for the adjacent decision or procedure that completes this constraint. |
Serve the complete chain and verify it from outside/deployhighstrictDeploy the leaf with required intermediates, keep roots out of the served chain, and test name and chain validation from representative clients.
| 1 | 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. |
| 2 | |
| 3 | - Configure the service with the leaf certificate followed by the required intermediate certificates in issuer order. |
| 4 | - Do not serve a private root as if it were an intermediate; distribute internal trust anchors through the client trust-management channel. |
| 5 | - Probe the public endpoint from outside the cluster or load balancer and inspect negotiated protocol, presented chain, hostname validation, and expiry. |
| 6 | - Test representative older and automated clients where compatibility matters; browser success alone does not prove command-line, mobile, or embedded trust behavior. |
| 7 | |
| 8 | See /ops/runbooks for the adjacent decision or procedure that completes this constraint. |
Limit private-key access and make replacement routine/infra/tlshighstrictGenerate and store keys in the narrowest execution boundary, prohibit copying across environments, and rotate by overlapping valid credentials.
| 1 | 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. |
| 2 | |
| 3 | - Generate keys through the approved secret, key-management, or workload-identity system and grant read or signing access only to the terminating service. |
| 4 | - Use separate keys for environments and independent services so one compromise does not require a fleet-wide emergency replacement. |
| 5 | - Do not place keys in images, repositories, logs, support bundles, or general environment dumps; mount or retrieve them through the platform's protected mechanism. |
| 6 | - Practice replacement with overlapping certificate validity and reload support, then revoke or remove the prior key after all terminating instances have changed. |
| 7 | |
| 8 | See /deploy for the adjacent decision or procedure that completes this constraint. |
Redirect to HTTPS without breaking bootstrap and recovery/deploymediumstrictMake secure transport canonical while preserving certificate validation paths, health behavior, and a staged route to strict transport policy.
| 1 | 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. |
| 2 | |
| 3 | - Determine the original scheme from a trusted proxy contract, not an arbitrary public header, before redirecting HTTP to the canonical HTTPS origin. |
| 4 | - Exclude or correctly route the certificate challenge path required by the active issuance method and test renewal through the production edge. |
| 5 | - Introduce strict transport policy only after every covered hostname works on HTTPS and the organization accepts the persistence and subdomain consequences. |
| 6 | - 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. |
| 7 | |
| 8 | See /infra/tls for the adjacent decision or procedure that completes this constraint. |
Memories
2Certificate renewal is an observed deployment loop/ops/runbooksAutomate issue, distribute, activate, verify, and alert stages, with enough lead time to repair the entire loop before expiry.
| 1 | 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. |
| 2 | |
| 3 | - Track certificate expiry from the outside and alert with enough lead time for failed issuance, approval, distribution, and rollback. |
| 4 | - After renewal, reload or roll terminating services through a bounded deployment and query each endpoint or region for the served serial and expiry. |
| 5 | - Monitor issuance and activation failures separately; one proves authority could not mint a certificate, the other proves the workload did not adopt it. |
| 6 | - Retain renewal logs and ownership without retaining private-key material so operators can distinguish DNS, rate, permission, and deployment failures. |
| 7 | |
| 8 | See /infra/tls for the rule or workflow that puts this decision into practice. |
Skills
1rotate-tls-certificate/rootIssue, stage, activate, verify, and retire a TLS certificate and key without interrupting supported clients.
| 1 | --- |
| 2 | name: rotate-tls-certificate |
| 3 | description: Rotate a public or internal TLS certificate, private key, intermediate, or trust bundle. |
| 4 | --- |
| 5 | |
| 6 | # Rotate Tls Certificate |
| 7 | |
| 8 | 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. |
| 9 | |
| 10 | 1. Inventory every terminating endpoint, identity, issuer, secret location, reload mechanism, client trust dependency, and owner affected by the rotation. |
| 11 | 2. Issue the replacement through the approved authority and validate names, usage, chain, key access, and challenge or enrollment evidence before distribution. |
| 12 | 3. Stage new certificate and trust material with overlap, then reload or roll a small target while retaining the prior credential for rollback. |
| 13 | 4. Probe handshake, chain, hostname, client authentication, protocol, and application health from representative networks and clients. |
| 14 | 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. |
| 15 | |
| 16 | ## Exit criteria |
| 17 | |
| 18 | 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. |
Why this pattern
AI agents often install only a leaf certificate, reuse private keys across environments, redirect challenge traffic incorrectly, or declare renewal solved without testing the deployed chain and next replacement.
Built for Platform and security teams operating public HTTPS and internal mutual TLS endpoints.
Keeps your assistant from:
- Serving a certificate that omits a production hostname
- Breaking clients by omitting an intermediate certificate
- Allowing broad filesystem or secret-store access to private keys
- Discovering failed renewal only after certificate expiry
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-08-25