Start by confirming that the bastion hostname is correct, port 80 is open to the public validation service, and the certificate can be requested in standalone mode. Once the certificate is issued, configure the proxy with the full chain and private key, then add an automated renewal mechanism so the setup stays valid after the initial installation.
What to verify before requesting the first certificate
The first setup decision is not the certificate request itself, it is whether the bastion is reachable in the exact way Let’s Encrypt expects for validation. Teams should confirm the hostname resolves correctly, the public validation path is open on port 80, and the certificate can be issued in standalone mode without colliding with an existing web service or proxy listener.
That order matters because validation failures are usually caused by reachability or binding problems, not by the certificate authority. If the host name is wrong or the challenge port is blocked, the request will fail before the certificate is ever created, so the setup should be tested from the outside first, then from the bastion service perspective.
For ssh bastion, the practical question is whether the validation workflow can run cleanly without disrupting the SSH proxy role. A standalone challenge is often the least ambiguous option because it makes the validation listener explicit and avoids dependence on a more complex reverse-proxy configuration during the first issuance.
How the certificate should be installed on the bastion
Once issuance succeeds, the next step is to place the certificate where the proxy or SSH front end actually consumes it, using the full chain and the private key together. The full chain matters because clients and intermediaries need the complete trust path, not just the leaf certificate.
This is the point where teams should check that the bastion process, file permissions, and service configuration are aligned. A certificate that exists on disk but is not readable by the correct daemon, or that is paired with the wrong key, produces an outage that looks like a trust problem but is really an installation problem.
The main operational detail is that the SSH bastion is not a browser-facing site, so the certificate is serving a narrower purpose: establishing trusted TLS for the proxy or management plane that wraps or exposes the bastion entry point. The configuration should therefore be treated as a service dependency, not a generic website certificate task.
Why renewal needs to be designed in from the start
Let’s Encrypt certificates are short-lived by design, so the final setup step should be automated renewal, not a manual calendar reminder. Renewal needs to be validated under the same conditions as issuance, including the expected hostname, challenge path, and service restart or reload behavior.
Teams should also verify what happens when renewal succeeds but the bastion does not reload the new material. In practice, the failure mode is often a stale certificate remaining active after a successful renewal job, which creates a false sense of stability until the next expiry date arrives.
Good renewal design also includes a recovery path for the common edge cases, such as temporary port 80 unavailability, DNS drift, or a changed listener on the bastion. The safest implementation is the one that makes renewal repeatable, observable, and low-risk to run unattended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Covers certificate and private-key handling for the bastion TLS setup. |
| IA-5 — Authenticator Management | Relevant because the bastion certificate and renewal workflow depend on managing authentication material securely. | |
| Recommendation — Protect the private key and automate certificate lifecycle handling. Track certificate issuance, storage, rotation, and renewal as managed authenticators. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Supports protecting the certificate private key and related secret material on the bastion. |
| CIS-12 — Network Infrastructure Management | Applies to opening port 80 and validating external reachability for issuance. | |
| Recommendation — Restrict access to certificate keys and store them only where needed. Verify inbound challenge access and document the bastion exposure path. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Applies because the setup depends on certificate use, key handling, and secure deployment. |
| A.8.9 — Configuration management | Relevant to the listener, proxy, and renewal configuration needed for stable issuance. | |
| Recommendation — Define how certificates and private keys are issued, stored, and renewed. Control and review the bastion configuration that serves the certificate and challenge path. | ||
Practitioner Guidance
What to verify: Test the full issuance path before production use, including public reachability on port 80, correct DNS, and whether standalone mode can bind cleanly without interrupting the bastion service. If any of those checks are uncertain, fix them before the first certificate request.
Decision rule: If the bastion already has another service on the validation port, do not force issuance through guesswork. Rework the challenge method or service layout first, because a clean first issuance is a better indicator of a stable deployment than a certificate obtained through temporary manual intervention.
What good looks like: The certificate installs with the full chain, the private key is protected by the correct service permissions, and renewal completes automatically with a verified reload so the bastion keeps serving a current certificate after the initial setup.
Practitioner takeaway: Treat the first Let’s Encrypt setup as an availability and validation exercise, not a certificate purchase task, because most early failures come from reachability and service-binding mistakes rather than the CA itself.
Related resources from NHI Mgmt Group
- What should teams do first when setting up a Fargate service behind an Application Load Balancer?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
