Your browser does not allow storing cookies. We recommend enabling them.

What are ephemeral certificates

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 ‘credentialess’, since on establishing the connection the user does not handle access credentials at all. Instead, the user logs in to the Certificate Authority each time he or she wants to establish a remote connection without having permanent authorization to the environment.

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 credentialess access. The configuration is static, meaning that it needs to be done only once when the servers are provisioned. Credentialess access does not change if 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 credentialess 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.

PrivX - just-in-time access authorization gateway

To enjoy the full benefits of ephemeral certificates, take a look at PrivX. It is just-in-time access authorization gateway that operates on the principle of least privilege and Zero Trust: grant the right amount of privilege for the right period of time to get the job done. Automate access administration by leveraging existing identity management solutions for efficient & secure user authentication and automatically discover multi-cloud and on-premises hosts.


 

 
PrivX
 

 

 
What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.



    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH



    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now