Why teams track GLPI certificates and domains in one inventory
Expiring certificates cause outages and audit findings when nobody owns the renewal. GLPI certificate and domain tracking records each TLS certificate and domain your organization runs, links it to the assets that serve it, and uses GLPI's certificate automatic action to send alarms on expired certificates so owners can act before a service breaks. According to the GLPI certificate documentation, the certificate management feature inventories organization certificates, follows their installation on assets, includes them in financial management and tracks renewal. Teams usually start this work after a renewal lapses unnoticed, or when an auditor asks who is accountable for a certificate and where it is installed.
The records need a named owner for each certificate and domain, normally the team that runs the service, with a contact who receives the alarms. Decide early who maintains the entries when a certificate is replaced, because a stale record gives false comfort. Your security or platform team typically owns the policy, while application owners own the installation links. Confirm with your own environment which assets, such as load balancers, web servers or appliances, should carry certificate links, since the documentation describes the feature but does not prescribe your renewal workflow.
Certificate tracking sits alongside the rest of your GLPI deployment rather than replacing a separate tool. It draws on the same asset records used for inventory, contracts and financial data, so the certificate, the host it runs on and the cost of renewing it can be viewed together. Check the GLPI 12 list of automatic actions for the exact certificate task behavior in the version you run, and confirm that the scheduled task execution is working in your deployment before you rely on the alerts.
What the GLPI certificate module does
GLPI's certificate module covers four connected jobs: keeping an inventory of organization certificates, recording where each one is installed, carrying its cost and renewal, and alerting people before or after expiry. Each capability depends on the records behind it, so the cards below also flag what to confirm in your own GLPI version before you rely on it.
Inventory of organization certificates
The certificate record is the central object: one entry per certificate with its issuer, validity dates and owning group or entity. Teams usually start by importing what they already track in spreadsheets or from their certificate authority exports. Confirm which certificate fields your GLPI version exposes by default and whether you need a plugin or custom fields for internal naming conventions, such as a certificate ID used by your PKI team.
Installation tracking on assets
GLPI follows where each certificate is installed, so a renewal shows which servers, load balancers or appliances need the new file. This link is only as good as the asset data behind it. Load balancers, reverse proxies and Kubernetes ingress often hold certificates that are not visible to discovery, so plan a manual or scripted check for those systems and confirm how your GLPI version associates certificates with each asset type.
Financial management links
Certificates can be included in financial management, which lets you record purchase or renewal costs against the certificate and report them with other managed items. Decide early who maintains these amounts, since renewal prices and billing periods change. Confirm how cost records are structured in your version before you migrate historical purchase data.
Renewal tracking
Renewal tracking keeps the expiry date and the responsible owner visible on the certificate record, so the team sees upcoming renewals in one place rather than in individual mailboxes. Agree on a renewal lead time with the owners and document it in the record. Confirm whether your GLPI version tracks domain registrations as their own record type, since many organizations track domains alongside certificates and the supplied facts do not settle that question.
Expired certificate automatic action
GLPI includes an automatic action that sends alarms on expired certificates. This is the mechanism that turns the inventory into warnings. Confirm in your installation that the action is enabled, that the cron task runs on the schedule you expect, and that the notification templates reach the right owners. Test it against a certificate with a past expiry date in a non-production instance before you depend on it.
Configuration decisions before you load certificates
This table compares the main setup choices for certificate and domain records in GLPI, with the situations where each fits and the upkeep it creates. Read each row as a decision to make before the first import, since most of these choices are hard to reverse once records and links exist at scale. The main takeaway is that linking records to assets and owners matters more for alerts reaching the right person than the record count itself.
| Decision | Option | When it fits | Maintenance cost |
|---|---|---|---|
| Record granularity | One record per certificate | Certificates are issued per host or service and renew on their own dates | Wildcard and multi-name certificates must be tracked in one place, so ownership of shared certificates needs explicit notes |
| Record granularity | One record per domain | Domains are the unit your registrar and legal team manage, and several certificates cover the same name | Domain expiry and certificate expiry are separate dates, so two alert paths must be kept in step |
| Asset linking | Link to the server, load balancer or appliance that presents the certificate | You need to know which system to touch during renewal and which services go down on expiry | Every replacement or migration of the host requires updating the link, which is easy to skip |
| Asset linking | Link to a business service or group of assets | Several hosts share one certificate, such as a cluster or a shared ingress | Service-level links are less precise for troubleshooting, so document which hosts actually install the certificate |
| Owning entity | Store records in the entity that operates the asset | Each business unit manages its own infrastructure and notifications stay inside that unit | Shared certificates across entities need a clear owner and may need visibility rules that match your access model |
| Owning entity | Store records in a central security or platform entity | One team buys and renews all certificates and needs one inventory view | The central team must keep owner and asset fields current for systems it does not run |
| Alarm recipients | Notify a named technical owner per record | Each certificate has a clear operator who can renew it | Owner fields go stale when people change roles, so review them on a regular schedule |
| Alarm recipients | Notify a group or mailbox | Renewal is handled by a team that rotates members or uses a shared operations channel | Group membership and mailbox routing must be tested, since a silent group is worse than no alert |
| Renewal tracking | Create tickets from renewal or expiry events | Renewals need an auditable record of who acted, when and with what outcome | Ticket templates, approval steps and closure rules need upkeep, and recurring tickets can pile up if nobody owns them |
| Renewal tracking | Rely on notifications only | The team is small, renewals are rare and a low-volume alert channel is enough | Notifications leave no work record, so proving a renewal happened depends on separate change records |
How to roll out certificate tracking in GLPI
This sequence moves certificate and domain tracking from scattered spreadsheets and memory into GLPI records linked to the assets they serve, with an expiry alarm that reaches named owners before renewal dates. Each step ends with a check that tells you the step is complete before the next one starts.
Confirm the GLPI version and automatic actions
Confirm which GLPI release you run and that the scheduled task mechanism is working, since the expired certificate alarm is an automatic action and does nothing if cron or the CLI runner is not executing tasks. Check the automatic action list in your version's documentation to confirm the certificate action is present under the name your release uses. Output: a written note of the GLPI version, the task execution method, and confirmation that the certificate action appears in the automatic actions list and can be run manually once.
Define the certificate and domain data model
Agree the fields and relationships before any data is entered. For certificates, decide which attributes matter for renewal (issuer, subject names, validity dates, the owning team, and the renewal process), and for domains, decide how registrar and DNS ownership will be recorded. Decide whether a domain is a separate record linked to certificates or a field on them, and define the naming convention so search works later. Output: a short data dictionary signed off by the security or infrastructure lead.
Load existing records from the source of truth
Export certificates and domains from wherever they are tracked today, such as a spreadsheet, a certificate store, a registrar export or a load balancer inventory, and map each column to the agreed data dictionary. Remove duplicates and records for retired hosts, and flag any certificate whose owner cannot be identified so it does not enter GLPI without an owner. Load in a test entity first and compare record counts against the export. Output: a reconciliation sheet showing source rows, loaded records and rejected rows with reasons.
Link certificates and domains to assets
Connect each certificate to the assets where it is installed, such as web servers, load balancers, appliances or applications, and connect each domain to the services or certificates that depend on it. Use GLPI's asset relations rather than free text in comments, so that a renewal can be traced to every system it affects. Spot-check a sample across each asset type, and list certificates that have no asset link for follow-up. Output: a report of unlinked certificates and domains with an agreed action for each.
Configure the expired certificate alarm and recipients
Set the expired certificate automatic action to run at the frequency your operations team agrees, and confirm the notification template and recipients. Assign alerts to the owning group or user for each record, and confirm that GLPI's notification settings can deliver mail from your environment. Ask your GLPI administrator to confirm the threshold logic in your version, because the alarm behavior and the timing of warnings should be verified rather than assumed. Output: a documented configuration with the action settings, the recipients per owner group and a test message received by each recipient.
Test with a known near-expiry record
Create or select a test certificate with an expiry date that falls within the alert window, linked to a test asset with a named owner. Run the automatic action manually and confirm that the alarm is generated, delivered to the right recipient and visible in the notification queue. Repeat with a test certificate that has already expired and with one that has no owner to see how exceptions are handled. Output: a test log with timestamps and screenshots or message copies, and a list of any fixes made before go-live.
Hand over ownership procedures
Document who updates the GLPI record when a certificate is renewed, who responds to an alarm, and who is accountable when a record is missing or wrong. Include the steps for adding a new certificate or domain, retiring one and reassigning owners when staff change. Train the owning teams on the record layout and the alarm workflow, and set a review of the inventory against the source of truth on a schedule your team agrees. Output: a signed operating procedure and a named owner for the GLPI certificate records.
Loading existing certificate and domain data
Before any certificate is entered into GLPI, the team needs one reconciled list drawn from several sources, because no single one is complete. Spreadsheets kept by the team that bought certificates usually show purchase and renewal dates but miss internal names. Network scans show what is actually served on each port, but cannot tell you who owns the certificate or which change window renews it. Certificate authority portals list what was ordered under the account, and web server configurations (Apache, Nginx, IIS, load balancers) show where each certificate is installed. Gather all four, then compare them. Any certificate that appears in a scan but in no spreadsheet or CA account is a risk to log first. Confirm with each CA which account and reseller identifiers you need to keep, and confirm with your platform team which endpoints you are permitted to scan.
Validate each record before it reaches GLPI. Check the subject names and subject alternative names against the domains actually served, the issuer, the not-before and not-after dates, and the serial number, which gives you a stable key for later deduplication. Duplicates are common: the same certificate appears in several load balancers, a wildcard covers many hosts, and a renewed certificate sits beside the old one until cutover. Decide one rule and apply it everywhere: the serial number identifies a certificate, while the domain and endpoint records describe where it is used. Keep an explicit field or naming pattern for the renewed successor so expiry alerts do not fire on a certificate that is already replaced. Use a naming convention such as the primary name, the issuer short code and the expiry year, and document it in the GLPI knowledge base so that imports from different teams look alike.
Assign an owner to every record before import, not after. An owner is the team or group accountable for renewal, and it should be a GLPI group that receives notifications, not a single person who may leave. Where ownership cannot be established from the sources, mark the record as unowned and treat it as a finding for the team that manages the domain registration or the application. Confirm with your GLPI administrators how entities and groups will separate records by business unit, since visibility follows the entity model. Finally, confirm how your team will load the data. GLPI's certificate documentation covers the inventory model, but the documents supplied for this section do not establish a bulk import method for certificates, so verify any import approach against the installed GLPI version in a test instance before relying on it.
What drives effort and cost in certificate tracking
This table lists the factors that change how much work certificate and domain tracking takes in GLPI, with a way to keep each one down and what to ask for in a quote. Read it before scoping, since most of the effort sits in data quality and ownership rather than in configuring the module itself.
| Driver | Why it changes effort | How to keep it down | What to ask for in a quote |
|---|---|---|---|
| Number of certificates and domains | Each record needs an owner, an expiry date and an asset link. Volume multiplies the cleanup and the review work, especially for wildcard and multi-name certificates. | Start with internet-facing and business-critical names. Retire expired or unused entries before importing the rest. | Estimated record count by type, how the work is split into phases, and whether bulk import is included. |
| Discovery sources to reconcile | Certificates often come from load balancers, web servers, cloud certificate stores, registrars and spreadsheets. Each source adds duplicates and naming conflicts to resolve. | Pick one system of record per certificate type. Agree matching rules for common name, subject alternative names and serial number before loading. | Which sources are in scope, who reconciles duplicates, and the rule set used for matching. |
| Asset linkage quality | Alerts only reach the right people when a certificate is tied to the server, appliance or service it runs on. Missing or stale links mean manual tracing during every renewal. | Link certificates to assets from the inventory that already exists, and treat unlinked records as a visible backlog. | Whether linking is done from existing inventory data or by hand, and how unlinked records are reported at handover. |
| Owner assignment | Expiry alerts are only useful if a named person or group acts on them. Assigning owners for hundreds of records usually needs input from application and infrastructure teams. | Assign owners by group rather than by individual where possible. Set a fallback owner for records with no clear team. | Who provides owner data, how long assignment is expected to take on the client side, and what happens to orphaned records. |
| Alarm and notification design | Thresholds, recipients and repeat rules must be set per certificate class. Too many alerts train teams to ignore them, and too few let certificates lapse. | Define a small set of warning windows and escalation paths before configuring the automatic action. Test with a sample of records first. | Number of alert classes, recipient rules, and the test plan for the expired certificate automatic action on your GLPI version. |
| Integration with ticketing or monitoring | Routing alerts into GLPI tickets or an external monitoring tool adds mapping work, authentication setup and failure handling for both systems. | Start with GLPI notifications and tickets. Add monitoring checks for live endpoints as a second phase if the team needs them. | Which target systems are in scope, how each integration is authenticated, and who owns the ongoing mapping changes. |
| Ongoing data upkeep | Certificates are renewed and replaced continuously. Without a renewal step in the process, records drift and alerts become unreliable within a short period. | Make renewal and replacement updates part of the change or renewal workflow, with a named reviewer. | Whether a support retainer covers record reviews and what the client team must keep doing after handover. |
How certificate records connect to the rest of GLPI and your tools
A certificate record is only useful for renewal planning when it points to the systems that present it. In GLPI, a certificate can be linked to the assets where it is installed, so an owner can see which load balancer, web server or appliance will break when the certificate expires. Populating those links is partly manual and partly automated, and the automated part depends on what the GLPI Agent actually collects on each device.
- Agent inventory: GLPI Agent gathers hardware and software inventory from Windows, macOS and Linux hosts. Confirm with your environment whether the certificate data you need is collected by default or requires a custom configuration.
- Manual linking: Appliances, network devices and cloud load balancers often have no agent. Plan who will link these assets and how often that review happens.
- Naming consistency: Match certificate subject names to the hostnames stored on assets, so the links are checkable rather than guessed.
- Ownership fields: Confirm that each linked asset has a technical owner, because the alert needs a recipient.
Before relying on the links, run a sample of known certificates through the process and confirm each one appears on the expected asset.
Certificates are also financial and contractual items. GLPI's certificate management includes financial management, so a certificate record can carry cost information and can be considered alongside the contracts that cover the vendors who issue or support it. This matters when renewals are budgeted, when a certificate is bought through a reseller, or when a domain is tied to a support agreement that renews on a different schedule.
- Cost fields: Decide whether purchase cost is recorded per certificate, per domain or per contract, and who maintains the figure.
- Contract links: Link certificates or domains to the contract that governs their renewal, so the contract's end date and the certificate's expiry are visible together.
- Budget planning: Confirm with your finance team how renewal spend is tracked and whether GLPI's financial records are the system of record.
- Multi-entity views: If your organization uses entities, confirm which entity can see and edit certificate costs.
Ask your finance and procurement leads to confirm which renewal cost data must live in GLPI and which stays in their own systems.
An alert tells someone that a certificate is close to expiry, but renewal work usually runs through a ticket. Connecting certificate records to the GLPI helpdesk lets the team open a renewal request from the certificate itself, keep the history of the work, and route it to the right group. Confirm how your ticket categories, assignment rules and approvals map to certificate renewal before you go live.
- Ticket creation: Confirm how a renewal ticket is raised from a certificate record in your GLPI version and what fields it copies.
- Routing: Decide which group handles renewal for each certificate type, such as public web certificates, internal CA certificates and code-signing certificates.
- Approvals: If a renewal needs sign-off before purchase, plan the approval step and its owner.
- Change linkage: If installing a renewed certificate counts as a change in your process, link the renewal ticket to the change workflow.
Walk through one renewal from alert to closed ticket with the team that will do the work, and record where manual steps remain.
GLPI's automatic actions include a certificate action that sends alarms on expired certificates. This is the built-in mechanism that notifies people about expiry, and it runs as a scheduled task rather than as a live check. The alert covers expired certificates, so your team must decide how to warn owners before the expiry date, and confirm what the action can and cannot do in your installed version.
- Scheduled task: Confirm the frequency at which the certificate automatic action runs in your environment and how it is configured in the scheduler.
- Expiry window: Confirm whether the action can warn before expiry or only after it, and plan any pre-expiry reminders through notification rules if the built-in behavior does not cover them.
- Recipients: Confirm who receives the alarm, whether that is the certificate owner, the linked asset owner or a group.
- Notification queue: Check that notifications are sent successfully and that the queue is monitored.
Test the alert with a certificate that expires soon in a non-production entity, and confirm the message reaches the intended recipient.
GLPI holds the record, but the live state of a certificate often lives elsewhere. Monitoring tools, external scanners and certificate discovery tools can see what is actually served on the network, which catches certificates that were never entered in GLPI. Connecting these sources requires a clear decision about which system is authoritative for each field, because two sources that disagree will undermine trust in the record.
- Discovery sources: Identify which scanners or monitoring tools see your public and internal endpoints, and what data they export.
- Import method: Confirm whether data comes in through a plugin, an API or a scheduled file import, and who maintains it.
- Authoritative fields: Decide whether expiry dates come from the live endpoint or the issuing record, and document the rule.
- Domain data: Domain registration and DNS records may come from separate registrars or DNS providers, so confirm where each domain's expiry is tracked.
Ask your security and platform teams to confirm which external sources exist, which fields each one owns, and how conflicts between them are resolved.
Questions teams ask before tracking certificates in GLPI
Can our team set up certificate tracking in GLPI without outside help?
Yes, if you have someone comfortable with GLPI administration and a clear list of who owns each system. GLPI includes a certificate management module that inventories organization certificates, follows their installation on assets, includes them in financial management and tracks renewal, according to the GLPI certificates documentation. The harder part is usually data collection: finding every certificate, its issuer, expiry date and the asset it runs on. A partner is most useful when you need that discovery work done across several teams or when the module must match an existing process. Confirm the module's options in your own GLPI version before planning the work.
What drives the cost and effort of this work?
The main drivers are the number of certificates and domains, how many asset types they attach to, and how many teams own them. Discovery effort rises when certificates live on load balancers, cloud services, appliances and internal hosts that are not already in GLPI. Integration effort rises if you want expiry data pulled from other tools instead of entered by hand. Costs fall into one-time items (design, data cleanup, configuration, testing) and recurring items (keeping records current and reviewing alerts). Ask any quote to list these components separately and to state which systems are in scope.
How long does certificate tracking usually take to set up?
Duration depends on the size of the estate and the state of your existing records. A small set of certificates on a few well-documented systems can be modeled quickly, while a wide estate with unclear ownership needs discovery before any configuration. Build time is usually shorter than the time spent agreeing owners, naming conventions and the renewal process. No duration is stated here without a researched source, so ask for a timeline based on your written scope, with phases for discovery, configuration, testing and handover.
What does the work need from our team?
You will need a named owner for each certificate or domain, access to the systems where certificates are installed, and a list of current certificates from your certificate authorities or hosting providers. You also need GLPI administrators who can configure asset types, profiles and notifications. Plan time for owners to confirm records, because alerts are only useful when the right person receives them. Decide early who handles renewal, who is notified before expiry and how a retired certificate is removed from the inventory.
Does GLPI replace our monitoring or certificate authority tools?
No. GLPI records what you own, where each certificate is installed and who is responsible for renewal. It does not issue certificates, and it is not a substitute for a tool that probes endpoints in real time. Many teams keep an external monitor for live endpoint checks and use GLPI as the system of record for ownership, contracts and asset links. Your certificate authority remains the source of issued certificates. Decide which system is authoritative for each data point before you configure alerts.
How do we confirm that expiry alarms behave as expected in our version?
Start by checking the automatic actions list for your GLPI release. GLPI's automatic actions include a certificate action that sends alarms on expired certificates, according to the GLPI 12 list of automatic actions. Then test it with a non-production certificate record set to expire soon. Confirm that the cron task runs, the notification reaches the right owner, and the alert is not sent to the wrong group. Document the test result and repeat it after each upgrade, since notification and cron behavior can change between releases.
Which records and links should we keep to support renewal reviews?
Keep the certificate's common name or domain, issuer, validity dates, owning team, the assets it is installed on, and the renewal contact. Linking each certificate to the asset it runs on lets you answer which services are affected before a renewal. For auditors, keep evidence that the inventory is reviewed on a schedule and that alerts were tested. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification.
What you receive when DeployOpen implements this module
The engagement ends with a written scope document and a configured certificate and domain data model that your team can run without us. The scope fixes which certificate and domain records are in scope, which GLPI entities own them, how certificates link to the servers, load balancers and appliances that present them, and which fields carry the renewal dates and owner names. You also receive documented linkage rules that state, for each certificate type, which asset relation must exist before a record counts as complete. Those rules are the part most teams let drift, so they are written as checks your technicians can repeat rather than as general guidance.
The alarm configuration is delivered with test evidence from a non-production run. DeployOpen sets up the certificate automatic action in GLPI, confirms the alert recipients and notification templates, and records the results of test certificates at several expiry points so you can see what an owner receives and when. A runbook for owners explains how to acknowledge an alert, renew or replace a certificate, update the linked asset and close the record. The evidence we prepare can support your internal control reviews or an independent assessor's work, but DeployOpen does not issue audit reports, attestations or certifications.
Before handover, you confirm several items that we cannot decide for you: the owner of each certificate and domain, the expiry lead times your policy requires, whether your certificate authorities or DNS providers offer data feeds that should replace manual entry, and which team receives escalations when an owner does not respond. You also confirm how your GLPI version and any plugins handle the automatic action, since upgrade paths can change scheduled task behavior. Ask for these confirmations in the written scope, and treat any item left open there as a risk to plan for before the first production alert.
How DeployOpen scopes and delivers GLPI certificate tracking
DeployOpen plans and implements GLPI certificate and domain tracking inside infrastructure you control, starting from a written scope that names the certificates, domains and asset records in play. The work covers the inventory model, the links to the servers and services each certificate protects, and the expiry alert configuration, with testing and handover to your own team.
How we scope
- Inventory which certificates, wildcard records and domains the organization must track, and where each one is currently recorded
- Map each certificate to the assets, load balancers and services it secures, and name the owner for each
- Agree in writing how far the scope extends, such as import of existing records or links to financial management
How we build
- Configure certificate types, statuses and financial fields in GLPI, then load records from your current sources under a documented mapping
- Link certificates to assets through the GLPI item relations so that expiry dates appear where operators already work
- Set up the expired certificate automatic action and notification targets, then test alerts against sample records before go-live
How we hand over
- Document the certificate data model, naming conventions, ownership rules and the alert recipients for your team
- Provide a runbook for renewing a certificate, updating its record and confirming the alert clears
- Walk your administrators through the automatic action schedule and the checks they should repeat after GLPI upgrades
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Review alert behavior and record quality when GLPI moves to a new minor release or the 11 and 12 upgrade path
- Confirm with your team which renewal and reporting needs a retainer should cover before the engagement starts
