Skip to content
Version v3.0.3

Certificate Management

Certificates Overview

Certificates are required to sign and encrypt tokens in ProAuth. ProAuth requires an X.509 leaf certificate with a matching private key for signing and decryption use cases. Password protection is optional.

Supported private-key inputs include:

  • base64-encoded PFX/PKCS#12 with or without a password;
  • PFX/PKCS#12 files;
  • PEM certificate plus PEM private key, including encrypted private keys with a password;
  • combined PEM files containing certificate and private key;
  • PEM certificate chains, when the selected leaf certificate has the matching private key.

Public-certificate-only inputs are not valid for ProAuth signing or decryption certificates. Accepted inputs are normalized internally as PKCS#12 certificate data before storage.

The following certificate types are distinguished:

  • Default
  • OIDC token signing
  • OIDC token encryption
  • ADFS OAuth token signing
  • AuditTrail signing

A Default certificate is created without dependencies and is always used if no specific certificates are found. An AuditTrail signing certificate is also created without dependencies to a subscription or a tenant. All other certificate types must always be assigned to either a subscription or a tenant.

If several certificates are found, the first attempt is always made to use the most specific certificate on a tenant level. If no such certificate is found, a search is made one level higher on a subscription level, and if no certificate is found there either, default certificates are finally used. If several certificates are found, the certificate with the longest validity period is always used.

Certificate levels search order for token signing or token encryption:

  1. Apply To Tenant
  2. Apply To Subscription
  3. Default

Certificate levels search order for AuditTrail signing:

  1. AuditTrail signing
  2. Default

Default Certificate

When ProAuth is started for the first time, a default certificate must be entered, which is then created as such in the database. Once a default certificate is available, it is no longer necessary to provide a certificate when starting ProAuth.

More certificates can then be managed by API, CLI import, or UI. The UI continues to support certificate file upload. The v2 API and CLI import also support the richer certificateInput object for PEM and file-reference based automation.