Use a certificate authority that supports automated domain validation, then point the bastion or proxy at the issued certificate and private key in its TLS configuration. The key operational requirements are that port 80 is reachable for validation, the certificate name matches the proxy hostname, and renewal is automated so HTTPS remains trusted over time.
How the certificate setup should fit the bastion and proxy
The core configuration goal is to make the bastion or proxy terminate TLS with a certificate whose name matches the public hostname users actually reach. That means the certificate and private key must be loaded into the proxy’s HTTPS listener, not bolted on as an afterthought, and the renewal path must be built into the same service configuration so trust does not break when the certificate changes.
For an SSH bastion that also fronts HTTPS, the practical choice is usually a certificate authority and automation flow that can renew without manual intervention. If the service is already exposed through a proxy, keep the certificate anchored to that proxy endpoint, because the browser trusts the hostname, the certificate chain, and the service presenting them, not the SSH function behind it.
The cleanest mental model is separate layers: SSH access is one control path, while HTTPS trust is another. You do not need to redesign the bastion to “become” the certificate endpoint, but you do need to ensure the proxy can read the certificate files, bind to 443, and survive renewals without interrupting the port or the hostname the client sees.
What has to be true for HTTPS to stay trusted
Three conditions matter most. First, domain validation must succeed, which often means the CA can reach the host on port 80 or another approved validation method is available. Second, the certificate’s subject or SANs must match the proxy hostname exactly. Third, renewal must happen automatically and reload cleanly, because an expired certificate on a bastion tends to create immediate access friction and support noise.
Operationally, the private key should stay on the bastion or proxy host with tight file permissions and limited administrative access. If the certificate is renewed by automation, the service must either reload the new material or use a deployment pattern that swaps certificates without dropping active connections. That is the difference between a working HTTPS front end and one that intermittently breaks access for users and tooling.
A useful check is whether the proxy is the real internet-facing identity. If users connect to a load balancer, reverse proxy, or ingress in front of the bastion, that outer layer should present the certificate, not the SSH daemon itself. The certificate should live where the TLS session is actually established, otherwise you end up solving the wrong problem and can still fail hostname validation even though the backend SSH service is healthy.
Where teams usually get this wrong
Many teams treat certificate issuance as a one-time task and renewal as an operations afterthought. That works until the expiry date arrives, the CA challenge can no longer be completed, or the proxy is restarted manually at the wrong time. Another common mistake is issuing a certificate for the server name the team prefers internally, rather than the public DNS name the client browser resolves.
Another failure mode is separating the certificate workflow from access control. The bastion may still function for SSH, but the HTTPS wrapper becomes untrusted, which can block admin portals, health checks, or browser-based access paths that depend on a valid certificate. For a broader view of certificate lifecycle and machine-facing trust, the Machine Identity, PKI and Certificate Lifecycle Guide is the best internal reference point.
For SSH-specific governance, the SSH Key and SSH Certificate Management Guide helps distinguish where SSH key management ends and HTTPS certificate handling begins, which is useful when teams run both on the same bastion host. If the bastion is part of a wider machine-to-machine trust pattern, the Guide to SPIFFE and SPIRE is helpful for understanding how certificate-backed workload identity is typically organized.
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, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate automation depends on controlled credential lifecycle and renewal handling. |
| SC-12 — Cryptographic Key Establishment and Management | HTTPS certificates rely on protected private keys and managed trust material. | |
| Recommendation — Automate certificate renewal and replacement under controlled authenticator management. Protect the private key and manage certificate material through approved cryptographic controls. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The bastion’s HTTPS trust depends on correct certificate and key use in TLS. |
| Recommendation — Define how TLS certificates and keys are issued, stored, and renewed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Operational access to certificate and proxy configuration should be limited and governed. |
| Recommendation — Restrict who can modify proxy TLS settings and certificate files. | ||
| OWASP ASVS | V12 — Secure Communication | The question is about establishing trusted HTTPS on the exposed proxy endpoint. |
| Recommendation — Validate certificate name, chain, and renewal behaviour on the HTTPS endpoint. | ||
Practitioner Guidance
What to verify: Confirm that the proxy is the TLS terminator, the certificate name matches the exact public hostname, and the renewal job can complete its validation without human intervention. If port 80 is part of the validation method, test it explicitly before relying on it in production.
Implementation sequence: Issue the certificate, install the certificate and key on the HTTPS endpoint, reload the proxy, then test renewal in a non-disruptive window. After that, monitor expiry time and reload behaviour together, because renewal success is not enough if the proxy fails to pick up the replacement material.
Common mistake: Teams often focus on making the certificate “valid” and overlook whether the proxy will remain reachable during renewal. The safer pattern is to automate issuance and reload as one operational unit, so certificate hygiene does not become an access outage.
Practitioner takeaway: Treat the bastion’s HTTPS certificate as a lifecycle problem, not a static configuration item, because hostname correctness and renewal automation matter more than the initial issuance step.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should NHS security teams reduce privileged access risk without disrupting clinical operations?
- How should security teams log privileged SSH access from bastion hosts?
- How should security teams govern SSH bastion access in privileged environments?
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
