Validating X.509 Access Certificates

When validating X.509 access certificates the target systems should consider the following.

Subject Names

PrivX users' username is encoded to their access certificates' subject common name. Target systems may use this information in audit logs to track which PrivX user is using the target system.

The target username is encoded to UPN subject alternative name (SAN). Target systems must always verify the UPN SAN matches the RDP / SSH username. Optionally target systems may use X.509 Name Constraints to restrict the name space allowed in the UPN SAN.

Extended Key Usage

PrivX uses the extended key usage to indicate the purpose for which the certificate was issued. The target systems should verify that the access certificate contains the expected extended key usage oids.

For RDP access certificates PrivX sets the following extended key usage:

  • Client Authentication (oid 1.3.6.1.5.5.7.3.2)
  • Smart Card Logon (oid 1.3.6.1.4.1.311.20.2.2)

For SSH X.509 access certificates the extended key usage depends on the used X.509 certificate authentication standard:

  • RFC 6187: Secure Shell Client (oid 1.3.6.1.5.5.7.3.21)
  • Tectia Server: Ssh Client (oid 1.3.6.1.4.1.2213.15.1.2)

Checking Certificate Revocation Status

PrivX returns certificate revocation lists (CRL) via the rest API. The access certificates contain HTTP certificate-distribution points (CDP).

PrivX-issued access certificates are single use and always tied to the target-system-login session. Therefore it is not mandatory for the target system to verify access-certificate revocation status. If target systems need to do this then HTTP access from target system to PrivX rest API is required.

Was this page helpful?

On this page