Certificates
Certificates are what allow systems to trust each other over the network. They expire, they can be revoked, and when something goes wrong with one, services go down. The Certificates section of Global Configurator takes that risk off your plate — upload a certificate once, and the platform tracks its health, warns you before it expires, and checks whether it has been revoked.
No more digging through server configurations to find out when a certificate expires. It is all in one place.
How It Works
Supported Certificate Formats
You can upload certificates in any of the following formats:
| Format | File Extensions |
|---|---|
| PEM (Base64 text) | .pem, .crt, .cer, .cert, .b64, .x509 |
| DER (Binary) | .der |
| PKCS#12 (Certificate + private key bundle) | .p12, .pfx |
| Java KeyStore | .jks, .keystore, .truststore |
| PKCS#7 / Certificate chain | .p7b, .p7c, .p7, .spc |
PEM (.pem, .crt) is the most common format for web and API certificates. PKCS#12 (.p12, .pfx) bundles the certificate and private key together — used when you need both. JKS files are typical for Java applications.
Uploading a Certificate
- Open Global Configurator and go to the Certificates section.
- Drag your certificate file onto the upload zone, or click to browse.
- The system immediately parses the X.509 structure and fills in these fields automatically:
- Issued By — the Certificate Authority (CN, Organisation, Organisational Unit).
- Issued To — the domain or system the certificate protects (CN, Organisation, Organisational Unit).
- Valid From / Valid To — the certificate's start and end dates.
- Key Usage — what the certificate is allowed to do (e.g., Digital Signature, Key Encipherment).
- Add a Description (required) explaining what this certificate is for.
- Tick Check for certificate Revocation if you want the system to verify the certificate has not been revoked.
- If the issuer certificate cannot be resolved automatically, an Add Root File section appears. Upload the root or intermediate CA certificate there.
- Set Days before expiry and add the email addresses that should receive expiry alerts.
- Optionally upload any additional related files (such as CSRs) using Add Other Files.
- Click Save.
The certificate file is stored securely in S3 or MinIO under a path like certificates/{name}/.
For PKCS#12 and JKS files, you will be asked for the keystore password so the system can read the certificate contents inside the bundle.
What Gets Recorded for Each Certificate
| Field | Description |
|---|---|
| Name | Friendly certificate name |
| Type | Certificate format (PEM, PKCS#12, JKS, etc.) |
| Description | What this certificate is used for |
| Issued By | CN, Organisation, and OU from the X.509 issuer field |
| Issued To | CN, Organisation, and OU from the X.509 subject field |
| Start Date | The notBefore date from the X.509 certificate |
| End Date | The notAfter (expiry) date from the X.509 certificate |
| Key Usage | Permitted uses extracted from the certificate (e.g., Digital Signature) |
| Status | Current health: HEALTHY, EXPIRINGSOON, or EXPIRED |
| Notify Before | How many days before expiry to send alert emails |
| Email Recipients | Who receives expiry notifications |
| OCSP Revocation Check | Whether revocation checking is enabled |
| Certificate Revocation Status | Last OCSP result: GOOD, REVOKED, or UNKNOWN |
| File Path | Where the certificate is stored in S3 or MinIO |
Certificate Status
Every certificate has one of three statuses, updated automatically every day at 4:30 AM UTC.
| Status | What It Means | What To Do |
|---|---|---|
| HEALTHY | The certificate is valid and not close to expiry | No action needed |
| EXPIRINGSOON | The certificate expires within 7 days | Start the renewal process immediately |
| EXPIRED | The certificate's end date has passed | Renew and replace as soon as possible — services may already be failing |
An EXPIRED certificate will cause connection failures in any system that validates it. If a certificate reaches EXPIRED status, treat it as an urgent incident.
OCSP Revocation Checking
OCSP (Online Certificate Status Protocol) is a way to ask a certificate authority in real time whether a certificate has been revoked — for example, because its private key was compromised.
When you enable Check for certificate Revocation on a certificate, here is what happens:
- The system reads the AIA (Authority Information Access) extension from the certificate to find the OCSP responder URL.
- It downloads the issuer's certificate (or uses the root cert you uploaded if it cannot resolve automatically).
- It builds and sends an OCSP request to the responder.
- The responder replies with GOOD, REVOKED, or UNKNOWN.
This check runs automatically every 3 days at 4:30 AM UTC for all certificates that have revocation checking enabled. You can also trigger a manual re-check at any time using the Refresh button in the certificate table.
| OCSP Result | Meaning |
|---|---|
| GOOD | The certificate is valid and has not been revoked |
| REVOKED | The certificate authority has marked this certificate as invalid — stop trusting it |
| UNKNOWN | The OCSP responder could not confirm the status |
Not all certificates support OCSP. Older certificates or those from private/internal CAs may not have an OCSP responder URL. In that case, the revocation check will return UNKNOWN, which is expected.
Expiry Notifications
You can configure automatic email alerts so the right people hear about an upcoming expiry well in advance.
How to set it up:
- In the certificate form, enter the number of days before expiry when the alert should fire.
- Add one or more email addresses to notify.
When do emails go out?
The system runs a daily check at 4:30 AM UTC. If today's date matches the calculated alert date (that is, expiry date minus notifyBefore days), notification emails are sent to all listed addresses.
Example: If a certificate expires on 1 June 2025 and you set notifyBefore = 30, an email goes out on 2 May 2025.
Set a generous lead time — 30 days is a sensible minimum for production certificates. Renewal processes often take longer than expected, especially when approvals or third-party CAs are involved.
Certificate Dashboard
The dashboard gives you an at-a-glance summary of your certificate inventory's health.
| Metric | What It Shows |
|---|---|
| Total Certificates | How many certificates are tracked in the system |
| Expiring Soon Count | Certificates that expire within 7 days |
| Healthy Percentage | Share of certificates currently in HEALTHY status |
| Expiring Soon Percentage | Share of certificates in EXPIRINGSOON status |
| Expired or Revoked Percentage | Share of certificates in EXPIRED status or marked REVOKED |
| Trend vs Previous Day | Whether each count has gone up, down, or stayed the same since yesterday |
Use the dashboard as your first stop when reviewing certificate health — you will immediately see if something needs attention without having to scroll through the full list.
Scheduled Monitoring Jobs
The system runs three automatic background jobs for certificate management:
| Job | Schedule | What It Does |
|---|---|---|
| Certificate Status Update | Daily at 4:30 AM UTC | Marks certificates as EXPIRINGSOON (within 7 days) or EXPIRED based on the current date |
| OCSP Revocation Check | Every 3 days at 4:30 AM UTC | Queries OCSP responders for all certificates with revocation checking enabled |
| Expiry Email Notification | Daily at 4:30 AM UTC | Sends email alerts to configured recipients when the notification threshold is reached |
You do not need to do anything to activate these jobs — they run automatically for all certificates.
Root Certificates
Some certificates, particularly those issued by private or internal Certificate Authorities, cannot be validated without their root certificate. This is common in enterprise environments where the CA is managed internally.
When does this come up?
- You enable revocation checking on a certificate.
- The system tries to find the issuer certificate to build the OCSP request.
- It cannot resolve the issuer automatically (because the CA is private or the chain is incomplete).
- An Add Root File section appears in the form.
Simply upload the root CA certificate (or intermediate certificate) there. The system uses it to complete the OCSP verification chain.
The root certificate is only needed for OCSP revocation checking. If you do not enable revocation checking, you do not need to provide a root certificate.
Additional Certificate Assets
Sometimes a certificate comes with related files — a Certificate Signing Request (CSR), an intermediate certificate, or other documentation. Use the Add Other Files section in the certificate form to attach these files alongside the certificate.
These additional assets are stored and linked to the certificate record. They are accessible for reference but are not used by the automated monitoring or revocation jobs.
The Certificates Table
The main Certificates list shows one row per certificate with these actions:
| Action | What It Does |
|---|---|
| Refresh | Triggers an immediate status and OCSP re-check for that certificate |
| Edit | Opens the certificate form to update description, notification settings, or add files |
| Delete | Soft-deletes the certificate record (flagged as deleted, not immediately removed) |
Related Pages
- Files — reusable uploaded assets that can be referenced in workflows
- Connections — credentials and system access configurations
- Import and Export — moving configuration between environments