Securing GLPI Agent communication

Why securing GLPI Agent communication matters for inventory data

Every GLPI Agent on an endpoint or network device sends data back to your GLPI server: hardware and software inventory, and in its network discovery role, details about the switches, routers, printers and other devices it finds on the network. According to the GLPI Agent documentation, the agent collects hardware and software inventory and sends it to GLPI, and it also performs network discovery and inventory, package deployment and remote ESX inventory. That traffic is only as trustworthy as the channel it travels over. If an agent cannot verify the server it is talking to, or if the server cannot be sure who is sending data, your asset records can be silently wrong, and in the worst case, an attacker positioned on the network can feed false records into your inventory.

The risk grows with the shape of your fleet. Multi-site estates, laptops that roam between office and home networks, and agents reaching GLPI across untrusted segments all widen the path the data crosses. Teams that run a private certificate authority need a clear answer to how agents will trust that CA, because the agent's trust configuration is where many deployments go wrong. Regulated environments add a further expectation: auditors and internal security teams will ask how inventory data is protected in transit, and they will want that answer tied to your own configuration rather than to a default. This is the situation where planning transport security before rollout pays off.

Before you commit to a design, confirm which trust options your agent version supports, including certificate validation, CA fingerprints, client certificates and any setting that forces SSL-only communication. Option names and behavior have changed across agent releases, so check the GLPI Agent documentation for the exact version in your fleet and test against a staging GLPI instance. Record the results, since the same checks will be needed after every agent upgrade and whenever the server certificate or private CA is renewed.

Options for securing GLPI Agent communication with HTTPS

This table compares five ways to protect inventory traffic from GLPI Agents to the GLPI server, from a publicly trusted certificate to enforcing SSL-only agents. Read each row for what the option protects against, what it asks of the fleet and operations team, and when it fits. The main takeaway is that the options are layered, and the trust model you choose determines how much work each agent update and certificate renewal will create.

Option	What it protects against	What it asks of the fleet and operations team	When it fits
Publicly trusted certificate chain	Interception and tampering on the path between agents and GLPI, with trust anchored in the operating system stores that agents already use.	Certificate issued by a public CA for the GLPI hostname, renewed on schedule. Agents need no extra trust configuration, but the hostname must resolve consistently for every network segment.	Agents reach GLPI over the internet or from many unmanaged networks, and the organization accepts a public CA for this endpoint.
Private CA with root distributed to agents	Interception and tampering by parties outside your PKI, with trust limited to certificates your organization issues.	Operate or buy an internal CA, deploy its root to every endpoint through your management tooling, and plan root and intermediate renewals. Confirm the trust store the agent on each OS reads.	Agents stay inside the corporate network, and you already run a managed PKI with an endpoint trust distribution process.
Certificate fingerprint pinning for private CAs	Substitution of a certificate by a rogue or misissued one, because agents accept only the expected certificate fingerprint.	Record the fingerprint of the server certificate, distribute it with agent configuration, and update it at every certificate rotation. Renewal without an agent update causes inventory failures. Confirm the exact setting in the GLPI Agent documentation for your version.	Certificates rotate rarely, the fleet is managed centrally, and you can coordinate pinning changes with each renewal.
Client certificates for mutual authentication	Unauthorized devices or scripts sending inventory data, since the server can require each agent to present its own certificate.	Issue, deploy and revoke a certificate per agent or per group, and handle enrollment for new devices and replacements. Confirm server and agent support for client certificates in your GLPI version before designing around it.	The organization needs to restrict who can submit inventory, such as in environments with strict device identity requirements.
Enforcing SSL-only agents	Agents falling back to unencrypted HTTP, which would expose inventory content and any credentials on the wire.	Configure the server to reject plain HTTP and confirm that every agent is set to use HTTPS. Find legacy agents still pointing at HTTP before enforcement, because those devices will stop reporting.	Any deployment with HTTPS available, which is most production deployments. Enforce it after the fleet has been migrated and verified.

How agent trust differs for public CA, private CA and air-gapped sites

When GLPI is published under a public name with a certificate from a publicly trusted authority, agents usually validate the server certificate against the trust store already present on the endpoint. Little extra configuration is needed, so the main work is confirming that the certificate chain is complete and that the name agents connect to appears on the certificate.

Validation path: Agents rely on the operating system trust store, so the certificate must chain to a root that endpoints already trust.
Distribution: Beyond the server URL, usually nothing else needs to reach endpoints, which keeps deployment packages and GPO settings simple.
Renewal ownership: The web or certificate team renews the certificate at the reverse proxy or load balancer, and agents are unaffected as long as the chain and name stay the same.
Rotation: Changing the public CA or the hostname is the event that needs planning, because agents configured with the old name must be redirected or reconfigured.

Check that the full certificate chain is served from every entry point, including load balancers, and confirm validation behavior for your agent version in the agent documentation.

Securing GLPI Agent communication step by step

This sequence moves agent traffic from unverified connections to HTTPS with validated certificates, then enforces encrypted-only communication across the fleet. Each step closes with a check, so the team knows the inventory path is protected before the setting is tightened.

Confirm GLPI is served correctly over HTTPS
The platform team confirms that the web server's document root points to GLPI's public directory, that URL rewriting routes requests through index.php, and that the site answers over HTTPS under the hostname agents will use. The installation documentation sets these requirements for Apache, Nginx, lighttpd and IIS, so check against the web server your team runs. Done when a browser and a command-line client both reach the login page over HTTPS without certificate warnings, and the server name matches the URL configured for agents.
Issue the server certificate and chain
The security or PKI team issues or selects a certificate whose subject alternative name matches the exact hostname agents will contact, then installs the full chain, including intermediate certificates, on the web server. A certificate that loads in a browser can still fail for a client that lacks the intermediates, so test the chain with a command-line TLS client from a host without your internal CA installed. Done when the chain verifies from that host, and the expiry date and renewal owner are recorded in your certificate inventory.
Choose the trust model for agents
Decide how agents will validate the GLPI server. If the certificate chains to a root that operating systems already trust, agents can rely on the system certificate store. For a private CA, agents need the CA certificate or a pinned fingerprint distributed through your deployment tooling, and you should confirm which fingerprint or certificate options your agent version supports. Client certificates add mutual authentication and need their own issuance, rotation and revocation process. Done when the trust model is written down for each platform in scope and each certificate or fingerprint has a named owner.
Test one endpoint with validation enabled
Pick a representative device from each operating system in scope and configure its agent to use the HTTPS URL with certificate validation turned on. Run a manual inventory or force a connection, then read the agent log for TLS errors such as an unknown issuer, a hostname mismatch or an expired certificate. Confirm the inventory appears in GLPI under the expected entity and that the device's last contact time updates. Done when every test device reports successfully, and the agent version and log settings used are recorded so the test can be repeated.
Roll the setting out in rings
Move the validated configuration to progressively larger groups, starting with the test devices, then a pilot group, then the remaining fleet, using the deployment method your team already uses for agents. Between rings, check that GLPI shows new contacts and that the number of devices failing to report is not growing. Keep the previous configuration available so a group can be rolled back without reinstalling the agent. Done when each ring has reported for the observation period set by your change process and no ring has unexplained failures.
Enforce SSL-only once agents report
When inventory from the fleet arrives over validated HTTPS, switch agents and the server side to accept only encrypted connections, so plain HTTP requests are refused. Confirm the setting name and its behavior in the GLPI Agent documentation for the version you run, because options for enforcing secure transport can differ between releases. List devices that still fail, such as those with outdated agents or outdated trust stores, and resolve them before the switch. Done when web server logs show no plain HTTP inventory requests for the observation period set by your change process.
Verify with agent logs and inventory results
Close the sequence by comparing evidence from three sources: agent logs for the connection method and any TLS errors, web server access logs for plain HTTP requests, and GLPI inventory results for devices updated since the change. Repeat these checks on a regular schedule and after each agent upgrade or certificate renewal, since log wording and supported trust options can change between agent versions. Done when the evidence shows validated, encrypted inventory from all in-scope devices, and the findings are filed with the change record.

Security risks in GLPI Agent communication and how to close them

Inventory traffic from GLPI Agent carries hardware and software data about every managed device, so the channel between agents and the GLPI server needs the same care as the server itself. The risks below share one root cause: a shortcut taken to get agents reporting, such as skipping validation or leaving a fallback enabled, that quietly outlives the rollout.

Disabling certificate validation to get agents working

Agents that fail against a new GLPI server often get pointed at it with certificate checks turned off. The agent then sends inventory to any host that answers on the expected address, so a spoofed or misrouted server receives the data. Check that no agent configuration, deployment script or GPO sets an option that skips verification. Owner: the platform team that builds the agent deployment package.

Trusting an unmanaged private CA

When GLPI uses a certificate from an internal authority, agents need that authority's trust chain or its fingerprint. Copying a certificate from one endpoint to every machine, with no record of who issued it, creates an unmanaged trust anchor. Keep the CA under your PKI process, document which fingerprints are approved and review them when the CA changes. Owner: the PKI or security engineering team.

Expired certificates that silently stop inventory

A certificate that expires on the GLPI server or in the agent trust store usually produces no alert in the console. Devices simply stop reporting, and the asset data ages without anyone noticing. Track certificate expiry dates alongside GLPI's own monitoring, and test renewal on a staging instance before the production date. Owner: the operations team that runs the GLPI web server.

Plain HTTP fallback left enabled

An agent or web server that falls back to unencrypted HTTP when HTTPS fails will send inventory in clear text on the network. Confirm that the agent is configured for SSL-only communication and that the web server does not serve GLPI over plain HTTP. Test this from a network segment where the agent must be unable to reach the server over HTTP. Owner: the network and platform teams jointly.

Unprotected agent credentials and tokens

Agent configuration can carry credentials or tokens that let a device submit inventory or reach GLPI APIs. If these values sit in readable deployment packages, shared file shares or scripts in version control, anyone with access can reuse them. Store them in a restricted location, limit each token to the minimum rights needed and rotate them when staff or deployment tooling changes. Owner: the endpoint management team with the GLPI administrator.

Inventory data exposed through web paths

GLPI's installation guidance places the web server's document root on the public directory rather than the installation root, with URL rewriting to route requests through index.php. If the root is set to the whole installation, configuration files, keys and data directories can become reachable over HTTP. Verify the document root and that sensitive directories return no content from outside. Owner: the web server administrator.

What breaks when certificate validation fails and how to roll out safely

The most common failure after a certificate change is an agent that can no longer reach GLPI at all, and it usually fails quietly. Once agents validate the server certificate, any mismatch between what they expect and what GLPI presents stops check-ins. The usual causes are a missing intermediate certificate in the chain served by the web server, a new certificate issued by a different private CA than the one whose fingerprint or bundle the agents hold, and a hostname on the certificate that does not match the server URL configured in the agent. Clock skew on either side can also make a valid certificate look expired or not yet valid. Confirm the chain with a client that validates the same way the agent does, and check the server clock against your time source before you change anything in production.

Fleets split between old and new agent versions are the failure that surprises teams most, because the same change works on some machines and not others. Older agents may use different TLS libraries or trust stores than current ones, so a chain that validates on a recent release can fail on an older one. Treat the agent version inventory as part of the change plan: identify which versions are deployed, test the new certificate against the oldest version you still run, and decide whether a version upgrade must come first. Do not rely on a single pilot machine to represent the fleet.

Roll out in stages with a pilot group, a rollback that keeps HTTPS, and a check-in review after each stage. Choose a pilot that covers each operating system and agent version in use, then widen the group only when agents from every segment have reported in on the new certificate. Keep the previous certificate and its chain available so you can restore the old configuration without switching agents to plain HTTP, which would expose inventory data on the network. Before each stage, record the expected check-in count per group and compare it with the GLPI agent logs and inventory dates afterward. Confirm the exact rollback steps and the agent-side settings for your version against the GLPI Agent documentation before the change window opens.

What to confirm before you enforce SSL-only agents

Enforcing SSL-only agents changes which endpoints, certificates and network paths must work on the first day. Each card below is one thing to verify in your own environment before you turn enforcement on, and the GLPI Agent documentation is the source of truth for every option name and default.

Agent versions and certificate options

Confirm the GLPI Agent version deployed on each platform and which certificate options that exact version accepts, such as a CA file, a certificate fingerprint or client certificate settings. Older agents may ignore options that newer ones honor, so a fleet with mixed versions can behave differently under the same configuration. Record the version per operating system before you change anything on the server side.

Agents in containers and on network devices

Agents running in containers, on appliances or on devices with a fixed trust store may not read the same CA bundle as your servers. Identify each non-standard agent location, where its trust store lives and who can update it. These agents often fail silently after enforcement because nobody owns their certificate bundle.

Endpoints used by GLPI 11 and 12

Check whether the GLPI version you run, 11 or 12, changes the endpoints that agents call, and whether your reverse proxy or web server rules route those paths to the same application. A rule written for one path layout can block inventory uploads after an upgrade. Test agent submissions against the target version in a staging instance before production enforcement.

Certificate renewal and CA rotation

Document who renews the GLPI server certificate, how long before expiry the renewal starts, and how a CA rotation reaches every agent. If agents pin a private CA or a fingerprint, a rotation can cut off the whole fleet at once. Agree on a rollout order that trusts the new chain before the old one is retired, and test it on a small group first.

Proxies and inspection devices on the path

Find every forward proxy, TLS inspection appliance and load balancer between agents and GLPI. Inspection devices re-sign traffic with their own certificate, which fails validation unless their CA is trusted by the agent. Confirm with the network team whether inspection applies to inventory traffic, and whether it can be exempted without weakening validation for other traffic.

Legacy agents still reporting over HTTP

Inventory any agents still sending data over plain HTTP, including retired hosts that keep reporting from old scheduled tasks. Enforcing SSL-only will reject these submissions, so they need either an upgrade or removal from the fleet. Use the GLPI inventory data itself to list agents that have not reported recently and match them against the HTTP endpoints in your logs.

What buyers ask about securing GLPI Agent communication

What drives the cost of securing GLPI Agent communication?

The main cost driver is how many distinct trust decisions the agent fleet needs: whether the GLPI server already has a certificate from a public or internal CA, whether that CA is private and must be trusted by every endpoint, and whether agents must present client certificates. Each of these adds design, configuration and testing work. The number of operating systems and deployment routes also matters, because Windows, macOS and Linux agents are configured and verified differently and each deployment channel (GPO, endpoint management, manual install) needs its own check. Scope is usually agreed in writing before work starts, and the quote should list the platforms, sites and deployment channels included. Ask whether certificate rotation and a runbook for expiry are part of the fixed scope or a later retainer item.

How long does securing agent communication usually take?

Duration depends on how much of the trust chain already exists and how many endpoints must be changed. A GLPI server with a valid public certificate and a fleet already managed by one deployment tool is the simplest case. A private CA, a mixed estate and client certificate enrollment take longer because each step depends on a decision from another team. Pilot testing on a small group of machines per operating system, followed by staged rollout, is typically where time goes. This page does not supply a duration, so ask any provider to base the timeline on the written scope and to name the dependencies, such as certificate issuance windows and change approval cycles, that could move the schedule.

What does the work require from our own team?

Securing agent traffic usually needs three groups of people. PKI owners decide the certificate chain, issue or approve the server and client certificates, and agree how revocation and renewal work. Web server administrators configure HTTPS on the GLPI host, confirm that the document root points to the public directory and that TLS settings meet your policy. Endpoint management owners push configuration changes, agent settings and any certificate or fingerprint material to devices, and they confirm rollout status. Plan time from each group before the project starts. Also name a person who can approve changes to production agent configuration, since a misconfigured agent can stop reporting inventory.

Can our staff secure GLPI Agent communication without a partner?

Yes, if your team has the skills in certificate management, web server TLS and endpoint deployment, and time to test. The GLPI Agent documentation describes the agent's server settings and runs on Windows, macOS and Linux, so an internal team can read it and build a test plan. The risks usually lie in the edges: a private CA trusted on some endpoints but not others, a certificate chain that omits an intermediate, or an old agent version that behaves differently. A partner adds value when several of these must be solved together, when you need independent verification, or when staff capacity is limited. Either way, define acceptance tests before you begin, such as a successful inventory run from a sample of each operating system.

What should a fixed-scope quote for agent security list?

A fixed-scope quote should be specific enough that you can check each item against your environment. Ask it to list the GLPI instances and their URLs, the certificate model (public, internal CA or client certificates), the operating systems and agent versions covered, and the deployment channels used to push changes. It should name the web server platform and the configuration steps for HTTPS, any fingerprint or CA material distributed to endpoints, and how SSL-only enforcement is tested and rolled out. Ask for the test evidence to be delivered, the rollback approach, the documentation handed over, and what is excluded, such as the Certificate Authority build itself or endpoint management platform changes. Ask which items are one-time and which recur, such as certificate renewal.

Does enforcing SSL-only agents create operational risk?

It can, if the rollout is not staged. Once agents are required to use HTTPS and validate the server certificate, any endpoint with a missing CA, an expired certificate or a wrong server name will fail to send inventory. Those failures may be silent from the user's point of view, so they show up as stale asset records. Mitigate this by testing on representative machines, monitoring last-contact times in GLPI after each wave, and keeping a documented route to revert a configuration change. Confirm with your certificate team how long a renewed server certificate takes to reach all endpoints, because that window sets how early you must renew.

Who is responsible for certificate renewal after go-live?

Renewal responsibility should be assigned in writing before go-live. The PKI owner usually issues and renews the GLPI server certificate and any client certificates, while the endpoint team pushes new trust material if the CA or fingerprint changes. Agree on the renewal lead time, who receives expiry alerts, and how a renewed certificate is tested against a sample of agents. If a retainer covers support after go-live, ask the provider to specify whether certificate renewal is part of it and how emergency changes are handled. Note that DeployOpen prepares systems and evidence but does not issue certificates, so the certificate authority remains your responsibility.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted GLPI inside your own infrastructure. For agent communication, we start from your certificate authority, your agent deployment method and your network paths, then deliver a written, fixed-scope set of changes that your team can run after handover.

How we scope

Inventory every agent entry point, including Windows, macOS and Linux fleets and any remote discovery tasks that reach GLPI.
Confirm whether your GLPI server uses a public or private certificate authority and which chain agents must trust.
Agree in writing which SSL-only enforcement, fingerprint or client certificate options are in scope and which are deferred.

How we build

Configure the GLPI web server for HTTPS with a certificate chain that agents can validate, following the GLPI document root layout.
Set up agent trust for private CAs, distributing CA certificates or fingerprints through your existing deployment tooling.
Test each agent platform against the new endpoint, checking that inventory still lands and that invalid certificates are refused.

How we hand over

Deliver the configuration, certificate renewal steps and rollback procedure as documentation your operations team can follow.
Walk your engineers through the verification checks so they can confirm agent communication after future changes.
Record the key files, configuration keys and trust anchors involved so audits and incident responders can trace them.

How we support

Plan GLPI and agent version upgrades so trust settings and agent configuration are retested with each change.
Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Ask any partner to confirm the agent versions, certificate options and deployment tooling supported in your environment before work starts.