When rotating GLPI encryption keys is worth the risk
Rotating GLPI encryption keys is worth the risk when you have a specific reason to believe a key has been exposed, when an upgrade or migration requires you to move the key files, or when auditors need to see how key handling is controlled. The two files at the center of this work are glpi.key, which protects values GLPI encrypts in its database, and glpicrypt.key, which holds the key used for the encrypted stored credentials. Anyone who holds a copy of these files together with a database dump can recover the protected values, so the question is not whether the keys matter but whether a rotation is the right response to the threat you are facing.
Rotation is not a routine click because GLPI must re-encrypt data it has already stored. If the new key is applied without that re-encryption, or if the old key is discarded before every value has been converted, stored passwords for LDAP bindings, mail servers and other integrations can become unreadable. Operators then face re-entering credentials across the instance, and the recovery depends on whether a valid backup of the old key still exists. Before you decide, confirm with your own GLPI version's documentation exactly which console command performs the re-encryption and which values it covers, because the installation docs linked from this page describe the update procedure, not every key operation in detail.
The rest of this page covers how to rotate, how to back up the keys before any upgrade, and what happens to stored passwords when a key is lost. If your situation is a suspected exposure, treat rotation as one step in a wider response that also includes reviewing who could read the files and the database, and changing the credentials that GLPI stores. If your situation is an upgrade, the key backup is a precondition and should be completed before application files are replaced. If you are preparing evidence for an assessment, record who authorized the rotation, when it ran and where the backup is kept.
Choosing between rotation, re-entry and keeping the current key
Rotate when there is evidence, or a credible reason to suspect, that glpi.key or the OAuth keys have left your control. Examples include a backup copy found outside the approved store, a former administrator with file access, or a compromised web or database host. Rotation changes the key material going forward, but it protects stored secrets only if the attacker did not obtain the database and the key together in usable form. Establish the scope of the exposure before you act, because that scope decides how much you must re-verify afterward.
- Scope of access: Determine whether the attacker read only the database, only the config directory, or both, since the combination is what enables decryption.
- Administrator actions: Administrators re-enter credentials for external services that GLPI stores, such as mail, LDAP and API accounts.
- Integration owners: Owners of OAuth clients and other integrations confirm their tokens and client settings still work after the change.
- Source-side rotation: Treat every password or token stored in GLPI as potentially exposed and rotate it at the source system as well.
- Change window: Schedule the work when the people who can check each dependent integration are available, and confirm in the GLPI documentation which steps the console task runs.
Before touching the console, confirm that you hold a verified backup of the config directory and have a written list of every integration that depends on a stored secret.
The GLPI update procedure already requires backing up the config directory, including glpi.key and glpicrypt.key, before application files are replaced and php bin/console db:update is run. Rotating a key in the same window adds a second change to a process that is already complex. The trade-off is fewer maintenance events against harder fault isolation: if something breaks, you cannot tell whether the upgrade or the new key caused it. For most teams the safer default is to upgrade with the existing key, verify the result, and rotate later as a separate change unless an exposure forces it sooner.
- Separate the changes: Complete the upgrade, verify it, and then schedule rotation as its own change record.
- Key backups: Keep copies of
glpi.keyandglpicrypt.keyfrom before the upgrade alongside the database and file backups. - Plugin owners: Since GLPI 11, plugins are suspended after a new version is detected and must be reactivated after major updates, so plugin owners must check their configuration after the upgrade.
- Path confirmation: Confirm the target version and its prerequisites in the update documentation before scheduling.
Before the upgrade window opens, check that a restore has been tested using the key files saved from the pre-upgrade config directory.
If glpi.key or glpicrypt.key is lost, rotation cannot recover values that were encrypted with the missing key. Generating a new key does not repair existing ciphertext, so the affected values must be re-entered or restored. Your first decision is whether a complete copy of the key exists, and whether it matches the database snapshot you plan to use. If a matching copy exists, restore it. If none exists, plan a re-entry exercise and treat it as a recovery project with named owners, not as a configuration tweak.
- Restore first: Search every backup of the config directory for a key file dated from the same period as the database snapshot.
- Map affected fields: List the mail, LDAP, API and integration credentials stored in GLPI and mark which ones the lost key protected.
- Re-entry owners: Administrators re-enter the stored passwords, and integration owners reissue or confirm client secrets at the source system.
- Avoid mismatches: Do not combine a key from one point in time with a database from another, since that can create a second failure that is harder to diagnose.
- Verify each integration: Test every dependent service after re-entry before declaring recovery complete.
Before you start, confirm with the GLPI documentation which fields are encrypted and what symptoms appear when a key does not match the data.
Most deployments do not need a rotation at any given time. Without an exposure, a planned upgrade or a lost key, changing the key adds a re-entry cycle, a verification cycle and new failure modes without a clear security gain. Keeping the current key is a valid decision when it is documented, the config directory is controlled, and the team knows where backups are kept. The decision should still be recorded so that the next person can see why the key was not changed.
- No trigger, no change: Absent a suspected exposure, a planned upgrade or a lost key, leaving the key in place avoids unnecessary disruption.
- Custody record: Record who can read the config directory, where key backups are stored and who approved that handling.
- Access review: Limit read access to the config directory to the accounts that run GLPI, and review that list when staff change roles or leave.
- Review triggers: Tie a periodic review to events such as host migrations, staff departures, or findings from a security assessment.
Before deciding to keep the key, confirm that its storage location and backup copies appear in your records and that someone outside the operating team could find them in an emergency.
Key rotation options and when each fits
This table compares several ways to handle GLPI encryption keys, from keeping current keys to rotating both sets in one change. Read each row by asking what changes, who must be told before the change, and whether a verified backup exists. Console menu names and exact steps vary by version, so confirm them against your installed GLPI release before scheduling any change.
| Option | What changes | Who is affected | When it fits |
|---|---|---|---|
| Keep current keys | Nothing changes. glpi.key and OAuth keys stay in place, and the config directory is backed up as usual. | No one beyond normal operations staff. | No suspected exposure and no rotation policy requirement. Record the decision and a review date. |
| Rotate glpi.key only | Replaces the key GLPI uses to encrypt stored values. Confirm the re-encryption steps for your version. | Administrators and any integration that stores credentials in GLPI. | The config directory may have been exposed and OAuth material is not in question. |
| Rotate OAuth keys only | Replaces the OAuth key pair. Confirm whether existing OAuth tokens stop working after the change. | API clients, SCIM consumers and cloud identity integrations using the OAuth2 API. | OAuth material may be compromised, or API clients are being reissued anyway. |
| Rotate both in a maintenance window | Changes glpi.key and the OAuth keys together, with backups taken and a rollback plan agreed first. | All administrators, users with stored credentials, and all API and SCIM clients. | Scheduled periodic rotation or a confirmed compromise, with integration owners ready to reconnect. |
| Defer rotation until after an upgrade | Keeps current keys through the update. The update procedure already requires backing up glpi.key and glpicrypt.key. | Operations staff and plugin owners, since GLPI 11.0 suspends plugins after a new version is detected. | An upgrade is imminent and no compromise is suspected. Schedule rotation as a separate later change. |
| Rehearse on a restored copy first | Applies the chosen procedure to a restored copy of the database and config directory before production. | Platform owners and the people who will run the production change. | Before any production rotation, to confirm console steps and integration impact. |
How to rotate the keys with the console safely
This sequence changes GLPI's encryption keys without losing access to stored secrets. Each step ends with a check, and the verified pre-change backup is the rollback point throughout.
Confirm the version and maintenance window
The GLPI administrator confirms the exact running version, including patch level, from the installed instance and compares it with the GLPI releases page. The change owner agrees a maintenance window with the people who depend on GLPI, because signed-in users and integrations may be affected while the keys change. Ask your implementation partner or the GLPI documentation to confirm whether the console command and its options differ for your version. Done when the change record names the version, the window, the approver and the rollback owner.
Take and verify full backups
Back up the database, the GLPI application files and the config directory, which holds glpi.key and glpicrypt.key. Store a copy of the key files in a separate, access-restricted location, since losing them makes encrypted values unreadable. Follow the backup requirements in the GLPI update documentation as the baseline. Verify the backup by restoring the database dump to a test instance and confirming the application starts with the copied config directory. Done when the test restore succeeds and the backup identifier is written into the change record.
Inventory every secret that depends on the keys
The administrator lists every stored value that GLPI encrypts, including directory bind credentials, mail collector and SMTP passwords, OAuth2 client secrets, API client settings and any plugin that stores credentials. Each entry gets a named owner who can supply the original secret if it must be entered again. Record where each item lives in the interface so it can be checked quickly after the change. Done when the inventory is complete and every owner has confirmed they can retrieve or reissue their secret outside GLPI.
Run the key change through the console
From the GLPI root directory, run the key change command in the GLPI console with the PHP binary, using the same system user as the web server so file permissions stay correct. Run only the key operation named in your version's documentation, and keep the old key files in place until testing passes. Watch the output for errors and note the exact time and command used. Done when the console reports success for each key and the change record lists which keys were rotated.
Re-enter or validate affected secrets
Open each item from the inventory and check whether GLPI still shows and uses its stored value. Where a value cannot be read or fails a connection test, re-enter the secret supplied by its owner and save the item again. Do not copy encrypted values between instances or from the old key files into the new configuration. Done when every inventory item either validates successfully or has been re-entered and then validated, with the results recorded.
Test sign-in and integrations end to end
Test sign-in with a local database account, an external directory account, and any other configured authentication method, then confirm that a test user sees the expected profile. Send a test notification, run the mail collector, issue and use a test API token, and confirm that scheduled tasks run without credential errors. Check the plugin list for any plugin that was suspended or reports an error. If a critical test fails and cannot be fixed within the window, stop GLPI, restore the files and config directory from the step 2 backup, restore the database from the same backup, and repeat the sign-in test. Done when all tests pass or the rollback is complete and verified.
Record the change and retain the rollback point
The change owner records the date, GLPI version, operator, backup identifier, keys rotated, secrets re-entered and test results in the change log. Keep the pre-change backup and the old key files for the retention period set by your own security and records policy, and mark them as restricted. Schedule a short follow-up check of authentication and integration logs in the days after the change. Done when the change record is complete, approved and linked to the retained backup.
Backing up keys before GLPI upgrades and migrations
The GLPI update procedure requires you to back up the database, the application files and the config directory, and the config directory is where glpi.key and glpicrypt.key live. Treat those two files as part of the database backup, not as an afterthought in the file copy. Encrypted values in the database, including stored passwords and some integration credentials, can only be read with the key set that was active when they were written. A backup that captures the database on Monday and the keys from a later point, or from a different server, produces a restore that starts but cannot decrypt what it holds.
Replacing the application files and running php bin/console db:update must not break that pairing. Before you start, record the GLPI version, take the database dump and copy the config directory in the same maintenance window, and write down a checksum for each key file. After the update, confirm that the key files are unchanged and that the instance still reads an encrypted field, such as a saved LDAP bind password, before you reactivate plugins. If the key files differ from your copy, stop and find out why before you continue. Since GLPI 11.0, plugins are suspended when a new version is detected, so the post-upgrade check is also the moment to plan plugin reactivation.
Store the key backups away from the GLPI server, in a location with its own access control, and keep each key file tied to the database snapshot it was taken with, labeled by date and version. Restoring a database without its matching keys is the failure to plan for, and it is also the reason to avoid keeping keys only in the same volume as the application. Confirm with your backup platform team how the key set is encrypted at rest and who can retrieve it during an incident, and test one full restore into a non-production instance before your first production upgrade. The GLPI installation docs on updates are the starting point for the file list your runbook should match.
What happens to stored passwords when keys are lost
GLPI encrypts some stored values with keys kept in its config directory, so the key files and the database are one recovery unit. Each card below describes a way that unit can fall out of step, and what to check before you rotate or restore. Treat encrypted values as unrecoverable until a test restore proves otherwise.
Lost glpi.key
The glpi.key file is the key GLPI uses to encrypt sensitive values stored in the database, such as credentials for external services and some authentication settings. If the file is deleted or not restored, GLPI cannot decrypt those values, and the affected settings must be entered again. Confirm which fields depend on this key in the GLPI documentation before you rely on it.
Lost glpicrypt.key
The glpicrypt.key file belongs to a separate key set used by GLPI for other encrypted data, so losing it does not automatically mean the glpi.key values are affected. Check which encrypted items in your instance rely on each key file. Keep both files in the same protected backup set so neither is missing when you restore.
Restoring a database without its keys
A database dump restored onto a server with a newer or different key file will hold encrypted values that cannot be read. This often happens when a backup taken before a key rotation is restored after the key was changed. Record the key file version alongside each database backup so the pair can be matched during recovery.
Restoring keys without their database
Key files restored without the database matching them give GLPI keys that decrypt nothing useful, because the stored ciphertext belongs to an earlier state. The error may only surface when a user opens an integration or a saved credential. Test each restore by opening a known encrypted setting after the database is loaded.
Key copies in weakly controlled backups
Backups that contain the database and the key files together give anyone with backup access both the data and the means to decrypt sensitive fields. Restrict read access to backup storage, limit who can retrieve key files, and log those retrievals. Ask your backup provider how access to archived copies is granted and reviewed.
Re-entering stored credentials
When a key is lost and cannot be restored, the credentials for LDAP binds, mail accounts, API connections and similar integrations must be entered again by an administrator. Plan a list of every integration before rotation, with its owner and the source system's credential process. Confirm the full set of re-entry fields against your GLPI version.
Questions teams ask before rotating GLPI keys
Can our own team rotate GLPI encryption keys without a partner?
Yes, if you have a staging copy, a tested backup and an engineer who can work through the console and database changes in a planned window. The main risk is not the rotation command itself but what the key change breaks: stored credentials, plugin data and integrations that depend on the old key. Teams with one administrator, no staging instance or no inventory of integrations usually find the work takes longer than expected, and a mistake in production can leave credentials unreadable. Start by listing every place GLPI stores secrets and every system that connects to it, then decide whether that list is something your team can own. If not, a partner can run the discovery and rotation under a written scope.
How long does a GLPI key rotation take?
Duration depends on what has to be found, re-entered and tested, not on the key change alone. The main drivers are the number of GLPI instances, the number of LDAP, mail, SSO and OAuth2 connections that store credentials, the plugins installed, the size of the database and whether a version upgrade is happening in the same window. Each integration that must be re-tested adds time, and so does any change board approval. Ask any provider for a schedule that lists staging rehearsal, production change, verification and rollback as separate phases, and confirm which of your systems each phase touches.
What does a partner quote for key rotation include?
A written quote should itemize the work, because cost follows scope. Typical components are discovery of where keys and encrypted credentials are used, a review of backup and restore readiness, rehearsal in a non-production copy, the production change itself, re-entry and testing of stored credentials, validation of each integration, a rollback plan and documentation for your records. Most of this is one-time work for a single rotation. Recurring costs appear only if you want policy-driven rotation, monitoring or ongoing support, which are usually separate retainers. DeployOpen does not publish prices, and each quote follows from the scope agreed in writing before work starts.
What does our team need to provide for a key rotation?
Your team provides access, backups, a change window and named owners. Before any change, take a full backup of the database, the application files and the config directory, and make sure glpi.key and glpicrypt.key are included, as the GLPI update procedure requires for upgrades. Name an owner for each connected system, such as your directory, mail server, SSO provider, OAuth2 clients and inventory agents, because someone must confirm that each one reconnects after the change. Also agree who can approve a rollback and who signs off on the test results. Without these owners, the rotation may finish technically while a sign-in or sync path silently fails.
What happens to stored passwords if a GLPI key is lost?
Values encrypted with a lost key cannot be decrypted, so GLPI cannot use them until someone enters them again. In practice this affects stored secrets such as directory bind passwords, mail account passwords and integration credentials. Sign-in for local accounts is a separate matter, but any connection that relies on a stored secret will fail until it is repaired. Confirm with the GLPI documentation for your exact version which fields are encrypted and where, and keep a current inventory of those secrets outside GLPI so they can be re-entered quickly. This is also why the key files belong in the same protected backup set as the database.
Should we rotate GLPI keys before or after an upgrade?
Back up the keys before any upgrade, and plan the rotation as a separate step unless you have tested the combined change. The GLPI update procedure requires a backup of the database, the files and the config directory that includes glpi.key and glpicrypt.key, followed by replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so every plugin needs a check after the change. Combining a key change with a major upgrade doubles the number of things that can fail in one window, so most teams sequence them and test each in staging first.
When should we bring in outside help for GLPI key rotation?
Bring in outside help when the rotation is urgent, when keys may have been exposed, or when the environment is too complex to change safely without a second team. Common triggers include a suspected compromise, a lost or unverified key backup, many connected directories or APIs, a plugin set that no one fully understands, or a regulated environment where the change record must hold up to an independent assessment. DeployOpen plans, implements and documents this work in your infrastructure and prepares the evidence an assessor will ask for, but it does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies.
How DeployOpen scopes key rotation work
DeployOpen plans and implements GLPI inside infrastructure you control, including your cloud accounts, data centers or air-gapped networks, so the glpi.key and OAuth key material never has to leave your environment for the work to proceed. Key rotation is scoped as its own piece of work because it touches the database, the configuration directory and every stored credential that GLPI encrypts. Before any change is made, the written scope should name which keys are in play, which encrypted fields are expected to be re-encrypted, which plugins store secrets of their own, and who on your side holds the backups and approves the change window.
Engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, and the deliverables for key rotation typically include a documented procedure, a tested rollback path, a backup verification record and a short runbook for the next rotation. Ask for each of these to be listed by name in the statement of work, and ask what evidence will show that the rotation succeeded, such as a successful login test, a checked integration and a confirmed restore of the backup taken beforehand. DeployOpen documents key handling as part of that output so your team can repeat it without the original engineers.
If you want the procedure rechecked after each GLPI release or plugin change, ongoing support, upgrades and testing can be covered by a retainer rather than a new project each time. DeployOpen does not issue audit reports, attestations or certifications. Where a key handling procedure is needed as evidence for an assessment, DeployOpen prepares the documentation and records, and the independent auditor or certification body makes the judgment. Confirm with your assessor in advance which records they will expect.
