When GLPI x509 certificate authentication fits your sign-in model
Use x509 certificate authentication when client certificates are already the identity your organization trusts. In that setup, a staff member presents a smart card or client certificate instead of typing a password, and GLPI reads the user's email address from the certificate subject to match or create the account. You can also restrict which organizations and common names GLPI accepts, so only certificates issued under your own policy can start a session. This fits organizations that already issue and revoke certificates for workstations, VPNs or other internal applications and want GLPI to follow the same lifecycle rather than maintain a second password store.
It is a weaker fit when most users have no certificate, when certificate issuance and revocation are handled by a team outside IT service management, or when you need a single sign-on flow that works across many applications. In those cases, a directory-backed login or an identity provider in front of GLPI may give you more control. Decide whether certificate sign-in replaces the password for everyone, runs alongside it for a subset of users, or is reserved for administrators, because that choice determines how you handle lockout, a lost smart card and the local administrator account that must remain reachable.
Before you commit, confirm the exact behavior for your GLPI version in the authentication documentation for that release, including which certificate fields GLPI reads, how it matches the email attribute, and how it behaves when the certificate chain or revocation status changes. Ask your certificate authority team which organization and common name values your issued certificates carry, and test with a sample of real cards in a non-production instance. The reader who checks these points first avoids discovering mismatched subject fields after rollout.
Which certificate fields and checks to configure
This table compares the x509 decisions you make before go-live: which certificate field supplies the email, how accepted organizations and common names are restricted, and whether local accounts keep a password path. Read each row as a question to answer for your PKI, then confirm the option labels and settings against your GLPI version in the authentication documentation.
| Decision | When it fits | What breaks if it is too loose |
|---|---|---|
| Subject attribute that holds the email | Use the attribute your issuing CA writes consistently into every user certificate, and confirm the exact field name in your GLPI version. | If the field is empty or differs between certificates, sign-in may match the wrong account or fail for valid users. |
| Accepted issuing organization (O) | Restrict to the organization your internal CA or smart card provider uses, so only certificates from that issuer qualify. | Any certificate chained to a trusted root could be accepted, letting staff from another organization or a partner CA sign in. |
| Accepted common name (CN) pattern | Match a defined naming scheme, such as employee identifiers or user principal formats, when the CA issues certificates to people only. | A wildcard or overly broad pattern can admit device, service or test certificates that were never meant for GLPI sign-in. |
| Trust of the CA chain in the web server | Configure the web server to require and verify client certificates against the issuing CA, and to reject revoked or expired certificates. | If verification happens only in the application, unverified or revoked certificates may still reach the login page. |
| Local account password path | Keep a password path only for a small set of named break-glass administrators, and confirm how GLPI handles fallback in your version. | Leaving password sign-in open for all accounts lets an attacker bypass the smart card requirement with a stolen or guessed password. |
| Mapping to existing GLPI users | Map each certificate email to a single existing or synchronized account, and confirm whether unknown users are created automatically. | Automatic creation with loose matching can produce duplicate accounts or grant profiles that were meant for a different person. |
| Logging and review of failed matches | Record rejected certificates at the web server and GLPI level, and review them after rollout to tune the rules. | Without logs, misconfigured CN or organization rules fail silently and users are locked out with no clear cause. |
Choosing a deployment model by how users connect
In this model, the web server that hosts GLPI terminates the TLS connection and requests a client certificate from the browser during the handshake. The web server or the PHP layer then exposes the certificate details to GLPI, and GLPI reads the email attribute from the subject and applies its own accepted organization and common name checks. Validation of the certificate chain happens on the web server, so the server configuration decides which certificate authority is trusted and whether a certificate is required or optional for the GLPI path.
- Trust store on the web server: The certificate authority bundle used to verify client certificates must be installed on the host running GLPI, and its file path and permissions must be reviewed.
- Optional versus required verification: Confirm whether the GLPI sign-in path should refuse requests without a valid certificate, or whether password sign-in must remain available as a fallback.
- Header or environment variables: Confirm which variables the web server passes to PHP for the certificate subject, issuer and chain, and check that clients cannot set those variables themselves.
- Certificate revocation: Confirm with the security team how revoked certificates are detected, since a locally verified chain alone does not check revocation status.
- Certificate rotation: Plan for the web server to be reloaded when the trusted authority or server certificate changes.
Before you commit to this model, confirm with the network and security teams who owns the web server configuration and who approves changes to the trust store.
In this model, a reverse proxy or load balancer sits in front of GLPI and handles the TLS handshake and client certificate validation. The proxy then forwards identity information to GLPI, usually as an HTTP header, and GLPI trusts that header. This moves the trust boundary from the application to the edge device, so the proxy's configuration, its certificate store and the path between the proxy and GLPI become part of the security design. Confirm the exact capabilities of your specific proxy product before building on them, because certificate handling and header forwarding differ between products and versions.
- Edge validation: Confirm that the proxy verifies the client chain and checks the certificate against the trusted authority before any request reaches GLPI.
- Header trust: Only accept identity headers from the proxy's own address, and strip any identity header a client sends in the original request.
- Proxy-to-GLPI path: Confirm whether the connection between the proxy and GLPI uses TLS, and who can reach the GLPI backend directly without passing through the proxy.
- Logging and audit: Confirm where certificate decisions are logged, since sign-in events may appear on the proxy rather than in GLPI.
- Multiple proxies: If requests pass through more than one hop, confirm which hop sets the identity header.
Before you build this model, ask the network team to document the proxy's validation settings and the header names it will send, and ask the security team to approve them.
On managed workstations, the organization controls certificate enrollment, storage and removal. Certificates are typically issued from an internal authority or delivered through device management, and they can be stored in the operating system certificate store or on a smart card. Because the organization controls the device, the certificate can be tied to an employee identity and removed when the device is retired or the employee leaves. The main design question is how the certificate's email attribute maps to a GLPI user, and whether that mapping matches the directory record that drives profiles and entities.
- Enrollment source: Confirm which authority issues the certificates, what subject fields it populates and whether the email attribute is set for every user.
- Storage and removal: Confirm whether certificates are stored on a smart card or in software, and how a lost or retired device is revoked.
- Attribute consistency: Confirm that the email value in the certificate matches the email stored on the GLPI user record.
- Browser behavior: Confirm which browsers and versions the managed fleet uses, and test how each one prompts for a certificate.
- Support path: Confirm who helps users who cannot sign in, and whether that path includes a local administrator account.
Before rollout, ask the endpoint team to confirm the enrollment and revocation process for the managed fleet.
Unmanaged devices include personal laptops, contractor machines and phones that the organization does not enroll. A certificate installed on such a device is harder to trust, because the organization cannot confirm the device's state or guarantee that the private key stays on it. In most cases, client certificate sign-in should be limited to managed devices, and unmanaged access should use another method that the security team has approved. If unmanaged access is required, the design needs stricter certificate issuance rules, shorter lifetimes and explicit approval from the security team.
- Issuance rules: Confirm whether the certificate authority will issue certificates to devices outside the managed fleet at all.
- Scope restriction: Confirm whether GLPI should refuse certificates issued to unmanaged devices, using the accepted organization or common name checks.
- Key protection: Confirm whether the private key can be exported, copied or stored in software on the device.
- Fallback method: Confirm which alternative sign-in path applies to unmanaged devices and whether it is covered by the same policy.
- Access policy: Confirm with the security team whether any GLPI profile should be limited when signing in from an unmanaged device.
Before enabling this path for any group, ask the security team to approve the issuance policy in writing.
Setting up x509 sign-in step by step
This sequence takes x509 sign-in from a certificate authority decision to a tested GLPI login. It ends with users signing in by certificate, limited to the organizations and common names you accept, with a tested local administrator path still available.
Confirm the certificate authority chain and profile
The PKI team confirms which certificate authority issues user certificates, that the full chain is available to the web server, and that each certificate carries the email address, organization and common name that GLPI will read. Issue one test certificate from the intended profile and check it with openssl verify against the chain. Confirm the subject fields on the test certificate match what your directory and the GLPI user records expect. Done when the chain validates and the subject layout is written down.
Configure the web server to verify client certificates
The team who runs the web server adds the trusted CA bundle and sets the server to request and verify a client certificate on the GLPI virtual host. Keep the GLPI public directory as the document root, as the installation docs require. Test three connections: no certificate, a certificate from an untrusted CA, and a valid test certificate. The first two must be refused at the TLS layer and the third must reach the GLPI login page.
Enable the x509 method in GLPI
A GLPI administrator opens the authentication settings and enables the x509 method. GLPI tries authentication methods in a fixed order, so confirm in the user documentation for your version where x509 sits relative to the internal database, LDAP and any REMOTE_USER setup. Before saving, open a second browser session signed in as a local administrator and keep it open until the change is closed. Done when the method shows as enabled and the existing local accounts still sign in.
Map the email attribute from the certificate
Set the certificate field GLPI reads to build the login identity, using the email attribute you confirmed in the first step. Check that each email value matches the email stored on the GLPI user record, including case and domain format. Sign in with a standard test user's certificate and confirm the session opens on that user's account and not another. Then try a certificate whose email matches no GLPI user and confirm it is refused.
Restrict accepted organizations and common names
Enter the organization and common name values that GLPI should accept, taken from the certificate profile you documented. Use the exact strings from the test certificate, since comparisons are sensitive to spelling and spacing. Present a certificate from the right authority with an organization value outside the list and confirm it is refused. Then present a certificate with an accepted organization and an unlisted common name and confirm it is also refused. Record each test result.
Test with a standard user and an administrator
Sign in with a standard user certificate and confirm the profile and entity assigned to that user match the expected access. Repeat with an administrator certificate, checking that administrative menus appear only where the profile allows them. Review the GLPI logs for both sign-ins and for the refused attempts from the previous step, confirming each event is recorded with the expected identity. Done when both roles behave as the access design specifies.
Confirm the local administrator path before closing
Before closing the change, sign out the certificate session and sign in with the local administrator account using its password. This confirms that a certificate fault, an expired intermediate or a misconfigured restriction cannot lock every administrator out. Document where the local credentials are held and who may use them. Close the change only after this login succeeds and the test results from every step are filed with the change record.
Where certificate trust can be lost
Certificate trust is lost when GLPI accepts a certificate that the organization never meant to trust. The most common cause is an overly broad trust anchor: if the CA bundle that the web server or GLPI relies on includes an authority that also issues certificates to contractors, partners or personal devices, any certificate that chains to it can sign in. A second cause is a loose match on the subject. Restricting accepted organizations and common names is what narrows the field, so a common name pattern that matches a whole class of machines, or an organization value shared across several issuers, quietly widens access. Before enabling sign-in, map who can issue certificates that chain to each trusted authority, which templates exist, and who controls them. That inventory tells you which organizations and common names are safe to accept and which must be excluded.
Two further failure modes come from the attributes and the path a request takes. An email attribute that is missing from some certificates will block legitimate users, but a duplicated value, or a certificate carrying two addresses where only one belongs to the account owner, can map a session to the wrong GLPI user. Confirm which subject field your certificate profile populates and test with certificates issued to several user types before rollout. The other risk sits in front of GLPI. If a reverse proxy terminates TLS and forwards identity headers to the application, a client who can reach GLPI without going through the proxy, or who can set those headers, can impersonate any user. The trust decision therefore belongs where the certificate is cryptographically validated, and the application should only trust identity data that its own validation layer produced. Check your proxy configuration and network path with the same care you give the trust store.
Security and operational controls to plan
Client certificate sign-in moves trust from passwords to a certificate authority, a directory of certificate fields and a short list of GLPI settings. The six controls below cover the trust chain, identity matching, revocation, recovery, key protection and monitoring, and each one separates what your PKI team owns from what the GLPI configuration controls.
Restrict the certificate authority chain
Decide which certificate authorities may issue certificates that GLPI accepts, and limit trust to the intermediate and root certificates your organization operates or formally recognizes. Your PKI team owns the issuance policy, certificate templates and key ceremonies. GLPI only trusts what the web server presents and validates, so the web server's client certificate settings and CA bundle define the real boundary. Confirm that no public or legacy CA chain is accepted by accident, and test with a certificate from an untrusted issuer before go-live.
Tighten organization and common name checks
Pair the accepted organization with the common name pattern you expect, so that a valid certificate issued to another organization or a different service cannot sign in as a GLPI user. Keep the list of accepted values short and written down, and review it whenever a business unit, certificate template or issuing CA changes. Test both a matching and a non-matching certificate for each accepted value, since a loose pattern is the most common way this control fails silently.
Plan revocation and expiry handling
A certificate that is valid in the web server's view may still belong to someone who has left or lost a smart card. Your PKI team owns revocation publication and the offboarding trigger, while the web server must be able to check revocation status for the CAs you trust. Decide how long a revoked or expired certificate may still work during a rollover, and document who disables the matching GLPI account when a credential is withdrawn, so that revocation does not depend on someone remembering to act.
Keep a tested administrator recovery path
Certificate misconfiguration can lock every user out, including administrators, when the x509 method is set as the only sign-in route. Keep at least one local administrator account that is not bound to certificates, protect its password, and test that it works before changing the authentication order. Write down the steps to switch the method back in the database or configuration if the web server stops passing client certificates. Confirm this path with your change board before any production cut-over.
Protect the encryption key files during changes
GLPI stores its keys in files such as glpi.key and glpicrypt.key, and changing or losing them can make encrypted stored values unreadable. Treat these files as part of every change window, back them up with the database and configuration, and restrict their file permissions to the web service account and the administrators who maintain them. Your team owns the backup vault and access approvals, while GLPI depends on the files being present and unchanged, so verify them after each update or restore.
Log and review failed sign-in attempts
Certificate failures happen at two layers: the web server rejects the handshake, and GLPI rejects a certificate it accepts at the transport level but cannot match to a user. Collect both logs in your central logging platform, and alert on repeated failures from one source, sudden spikes after a CA change, and sign-ins from accounts that were recently revoked. Your security operations team owns the review cadence and retention, while GLPI and the web server supply the events, so confirm which log file captures each failure type in your build.
What teams ask before enabling GLPI certificate sign-in
How much effort does GLPI certificate sign-in take to set up?
The effort depends on how many moving parts your environment already has, not on GLPI itself. The main drivers are whether your certificate authority already issues user certificates with an email address in the subject, how many user populations need certificate sign-in, whether you also keep local or LDAP accounts for administrators, and how many organizations and common names you need to restrict accepted certificates to. A single site with one internal CA and one user group is a very different job from a multi-entity deployment with several issuers. Ask any provider to break the work into PKI review, GLPI configuration, web server settings, testing and handover, and to show which of those items depend on your teams.
Can our internal team enable x509 sign-in without a partner?
Often yes, if your team already runs the web server, understands your PKI and has tested client certificate handling before. The work touches four areas: the web server must request and pass client certificate details to GLPI, GLPI must read the email attribute from the subject and apply the accepted organization and common name restrictions, your certificate issuance must produce certificates GLPI can match, and users must have certificates installed on their devices. A partner adds most value where these areas cross team boundaries, or where you need a documented test plan and a rollback path before users are affected. Confirm which of these skills you have in-house before deciding.
What does the work need from the PKI, network and identity teams?
Each team owns a different piece of the sign-in path, so agree on their inputs early:
- PKI team: confirm the issuing CA chain, the subject format that carries the user's email address, the organization and common name values you will accept, and how certificates are revoked and renewed.
- Network team: confirm how TLS terminates, which load balancer or reverse proxy handles client certificates, and whether the path to GLPI preserves the certificate information.
- Identity team: confirm how certificate holders map to GLPI accounts, whether those accounts already exist, and which profiles and entities they should receive.
Gaps in any of these usually surface during testing, so ask each team to review the test plan before the change window.
How long does testing take, and what sets that duration?
Testing length is set by the number of certificate types, user populations and environments you must verify, not by a fixed rule. Plan for separate passes covering valid certificates from each issuer, expired and revoked certificates, certificates with unexpected organizations or common names, users who should be denied, and administrators who still need a fallback login. Each additional issuer, each extra entity or profile, and each proxy hop adds cases. Ask for a written test matrix with expected results and a named owner for every case, because that matrix is the clearest measure of how long the work will take.
What changes for users who currently sign in with passwords?
For users moved to certificate sign-in, the visible change is that the browser or operating system presents a certificate instead of asking for a password, and the user must keep that certificate installed and valid. Passwords may still work for accounts you have not moved, so decide which users lose password access and when. Plan communications for certificate renewal, what to do when a device is lost or replaced, and who to contact when sign-in fails. Confirm whether the change affects mobile devices, shared workstations and service accounts, since those often need a separate path.
What should a quote for this work include?
A quote should follow directly from a written scope, and DeployOpen agrees scope, deliverables and timelines in writing before work starts. Ask that the quote list each area of work (PKI review, GLPI configuration, web server changes, test matrix execution, rollback plan, documentation and handover), the environments covered, the number of certificate issuers and user populations, and the assumptions your team must meet, such as access to the CA and load balancer configuration. Ask separately which items are one-time, such as configuration and testing, and which recur, such as certificate management or retainer support. DeployOpen does not publish a price list, so the quote is the place to see how each component is priced.
Does x509 sign-in replace the need for a fallback administrator account?
No, you should keep a tested fallback path for administrators. If a certificate authority is unavailable, a certificate expires, or the web server configuration breaks, you need a way to recover access without disabling the platform. Many teams keep a local administrator account protected by a strong password and reviewed access, and test that the fallback works before enabling certificate sign-in for everyone. Confirm with your identity team how that account is stored, who can use it and how its use is logged, and include the fallback test in the acceptance criteria.
Which compliance evidence does certificate sign-in produce?
Certificate sign-in produces evidence about how users authenticate, but it does not make a system compliant on its own. Useful records include the configuration of the accepted issuers and subject restrictions, test results showing denied certificates are rejected, the access control decisions made for each certificate holder, and the change records for the rollout. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or certifications. Ask your auditor which records they expect before you define the evidence set.
Limits to confirm in your environment
x509 sign-in depends on several layers working together: the GLPI version and its requirements, the web server and TLS termination in front of it, the certificate profiles your PKI issues, and how revocation is handled. Confirm each layer before you choose this method over LDAP, SSO or local accounts.
Supported versions and exact options
Confirm which GLPI release includes the x509 method and the exact option names, field choices and defaults it exposes in your version. Do not rely on older blog posts or forum answers, because the authentication screens have changed across the 10 and 11 lines. Check the release notes for the version you plan to run and test the options on a non-production instance before you write them into a runbook.
Web server and TLS termination
Decide where the client certificate is verified: in Apache, Nginx or IIS directly, or at a load balancer or reverse proxy. The web server must request the certificate, pass the subject values through to PHP in the form GLPI expects, and prevent clients from spoofing those headers. Confirm this path with the same TLS settings your users will reach in production, including any proxy that terminates the connection.
Certificate subject and email attribute
Check that your certificate profiles place the user's email address in the subject field GLPI reads, and that the value is consistent across users. Issue a sample certificate from each profile your organization uses, then inspect the subject with a standard tool. Smart card profiles from some providers store the email in a different field, so a mismatch here blocks sign-in for a whole group.
Revocation checking in your PKI
GLPI does not replace your certificate revocation process. Confirm how your PKI publishes revocation data, whether through CRL distribution points or OCSP, and whether the web server or proxy checks it before passing a certificate to GLPI. Ask your PKI team how long a revoked smart card or departed employee's certificate remains usable, and document who can trigger revocation.
Interaction with other sign-in methods
Confirm the order in which GLPI tries its authentication sources and whether x509 users can still reach local accounts, LDAP-backed accounts or other external methods. Decide which account keeps working if the certificate infrastructure fails, and make sure that fallback path is itself protected. Test a locked-out certificate user and a local super-administrator sign-in before go-live.
Platform requirements for your version
Verify that the chosen GLPI release's PHP and database requirements match your servers, and that your web server layout follows the installation docs. Also confirm that the database engine and version are supported for that release. Plan the upgrade path to the next major line now, because x509 settings and plugin compatibility must be retested after any version change.
How DeployOpen scopes and delivers GLPI sign-in work
DeployOpen plans, implements, tests, documents and supports GLPI client certificate sign-in inside your own infrastructure. Engagements are fixed-scope, with the certificate fields, trust chain and access restrictions agreed in writing before any configuration changes are made to your GLPI instance.
How we scope
- Inventory the certificate issuer, trust chain and the subject fields your users carry today
- Agree which email attribute and which organization and common name values GLPI should accept
- Define the fallback path for local administrator accounts and users without certificates
- Record the scope, deliverables and timeline in writing before work starts
How we build
- Configure the web server to request and validate client certificates against your certificate authority
- Map the email attribute from the certificate subject into GLPI user records and test the match
- Restrict accepted organizations and common names, then test rejected and expired certificates
- Keep the work inside your servers, cloud accounts or data centers, with your staff in the loop
How we hand over
- Document the web server layout, trust store location and the GLPI settings changed
- Provide a test script that covers accepted, rejected, revoked and expired certificate cases
- Walk your administrators through the rollback steps and the recovery path for locked-out users
- Confirm with your team how certificate renewal and revocation feed into GLPI access
How we support
- Review the configuration after each GLPI minor or major upgrade and after plugin changes
- Ongoing support, upgrades and continuous testing are available as a retainer
- Recheck certificate rules when your certificate authority or naming standard changes
- Agree the support response and change process in the retainer terms before go-live
