Ephemeral Certificates and Ephemeral Access

One of the most common methods of establishing a secure remote connection between a client and a server is by using the Secure Shell protocol and SSH key pairs which are configured for the client and the server separately. Typically, this type of access is called privileged access, since the connection is made to environments with highly valuable or sensitive information.

However, key configuration is often manual and time-consuming, especially in fast-moving multi-cloud and hybrid environments, where access needs are often temporary and changes are constant.

Moreover, SSH keys never expire by default and can be self-provisioned without proper governance, and often provide too much privilege for the task at hand, which decreases the security posture of the environment.

Ephemeral, certificate-based access operates differently. While the connections are still established using existing encryption protocols (SSH/RDP/HTTPS), the primary method of access to the target host is authorized using various industry-standard certificates.

Even if the target server does not support certificate-based access, there are other options available.

How do ephemeral certificates work?

In ephemeral certificate-based authorization, the target systems are accessed without the need for permanent access credentials, explicit access revocation or traditional SSH key management.

For each session, the ephemeral certificate:

• is issued from the Certificate Authority, which serves as the trusted third party

• is based on various industry-standard methods, the chief example being the short-lived X.509 certificate

• encodes the target user ID for security

• has a short lifetime (5 minutes) after which it auto-expires

The access is also called ‘credential-less, keyless or passwordless, since on establishing the connection the user does not handle or see privileged access credentials at all.

Instead, the user logs in to the Certificate Authority each time he or she wants to establish a secure remote connection without having permanent authorization to the environment.

This always-temporary access aligns well with the Zero Trust framework which stipulates that every connection should be verified each time it is made.

It also supports the Just-in-Time authentication paradigm where the secrets needed to access a target are created on the fly at the time of establishing the connection, but then expire soon after. This leaves no secrets behind to misuse and ensures that every connection is established every time as a fresh instance without permanent, always-on authorization.

User access configuration

The Certificate Authority controls access to the target system based on user roles, which are created based on rules. The rules for particular roles are generated according to security policies and access requirements.

The Certificate Authority fetches the rules for each role from the IAM system and uses them to determine proper authentication. This system alleviates setting up access for each individual user and enables streamlined updates to groups of users.

Target system access configuration

The target systems must be configured to support credential-less access. The configuration is static, meaning that it needs to be done only once when the servers are provisioned.

Credential-less access does not change if the user roles/job functions change or users are added or removed from the identity management system. The target systems must be re-provisioned only if there are changes in the roles and their mappings to the operating system level accounts that define which access roles have the right to perform which functions on the target server.

The configurations that allow credential-less access are like templates that serve a function. This means that multi-cloud instances (such as Amazon Web Services, Microsoft Azure, Google Cloud or OpenStack) can be scaled up and down at will, but the templates remain immune to the changes and continue to provide access as per purpose, for example, access to financial data, system databases, production environment etc.

Ephemeral certificates in conjunction with secure protocols

OpenSSH certificates

The SSH access is implemented with OpenSSH certificates. The certificates encode the user roles and the SSH server configuration on the target server maps the roles into the operating system level accounts.

Windows RDP access

The Windows RDP access is implemented with a virtual smart card. The Certificate Authority acts as the smart card in RDP authentication. The smart card’s certificate is created on-demand when the user opens the RDP connection.

The certificate is enrolled for an ephemeral keypair which is discarded after the authentication has been completed. The virtual smart card authentication is fully automated and invisible for the end users.

Non-certificate access

If the target server does not support OpenSSH or RDP certificates, the Certificate Authority uses role keys instead. The role keys are standard SSH keypairs. The public key associated with the role key is configured for the file that defines which private keys are allowed to access the target host, and the corresponding private key is held in the Certificate Authority secure key storage.

The user will never get access to the private key that is associated with the role. Users can only use it indirectly via the Certificate Authority to authenticate and authorize the access, based on their access role defined in the Certificate Authority.

Ephemeral certificate-based solutions

SSH, the company, has developed a comprehensive set of just-in-time (JIT) Zero Trust solutions that support ephemeral certificates for user or machine ID authentication.

This helps to mitigate the risk and overhead of managing digital keys (like SSH keys), privileged passwords and other secrets (like API tokens or certificates) by greatly reducing their numbers in IT infrastructures.

Learn more about the SSH's Zero Trust and Just-in-time (JIT) solutions below.