> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-reference/certificate-filter-certificationcheck.md).
# Certificate Filter (CertificationCheck)
**Audience:** IT admins authoring or reviewing KEPM policies in JSON who need to scope a policy by the code-signing certificate of the target binary.
## Overview
`CertificationCheck` is a policy filter array that restricts a policy to requests whose target binary is signed by a specific certificate (or set of certificates). It is paired with the built-in `CheckCertificate()` rule expression, which evaluates the array at policy-match time.
The filter is honored by the following policy types:
* `FileAccess`
* `PrivilegeElevation`
* `HttpAccess`
For other policy types, the field may be present in the JSON (the management console emits it by default) but is not evaluated.
## JSON Structure
`CertificationCheck` is a top-level array of certificate hash strings, sibling to `UserCheck`, `MachineCheck`, and `ApplicationCheck`. It is paired with a rule entry that invokes `CheckCertificate()`.
```json
{
"PolicyName": "Allow elevation for binaries signed by Vendor X",
"PolicyType": "PrivilegeElevation",
"Status": "enforce",
"Rules": [
{
"RuleName": "CertificateCheck",
"ErrorMessage": "Certificate hash is not included in this policy",
"RuleExpressionType": "BuiltInAction",
"Expression": "CheckCertificate()"
}
],
"CertificationCheck": [
"HASH1",
"HASH2"
]
}
```
The rule entry is required for the filter to be evaluated. Policies emitted by the management console include the rule entry and an empty `CertificationCheck: []` array by default.
## Match Semantics
| Configuration | Behavior |
| ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- |
| `CertificationCheck: ["*"]` | Matches any certificate. The policy applies regardless of which certificate signed the target binary. |
| `CertificationCheck: []` (empty array) | Matches any certificate. Equivalent to `["*"]`. This is the management-console default. |
| `CertificationCheck: ["HASH1"]` | Matches only requests where the target binary's certificate hash equals `HASH1`. |
| `CertificationCheck: ["HASH1", "HASH2", "HASH3"]` | Matches if the target binary's certificate hash equals any value in the array (OR logic). |
| Request has no certificate hash (binary is unsigned or hash unavailable) | The policy does not apply, unless `CertificationCheck` is `["*"]` or empty. |
Hash comparison is case-insensitive (hashes are normalized to uppercase during preprocessing).
## Preprocessing Notes
* Hash values in `CertificationCheck` are direct strings, **not** collection UIDs. Unlike `UserCheck`, `MachineCheck`, and `ApplicationCheck`, the array does not reference Keeper collections.
* Hashes are normalized to uppercase at preprocessing time. Authoring the array in lowercase or mixed case is acceptable.
* The preprocessed snapshot can be inspected in `currentPolicies.json` (see Policy JSON & Extension) to confirm the resolved hash list for each policy.
## Combining with Other Filters
`CertificationCheck` is evaluated alongside the other six built-in rule expressions (`CheckUser`, `CheckMachine`, `CheckFile`, `CheckDate`, `CheckTime`, `CheckDay`). The policy's top-level `Operator` field (`"And"` / `"Or"`) determines how the rule results combine.
To scope a policy to a specific certificate **and** a specific application path, set both `ApplicationCheck` and `CertificationCheck`, and keep `Operator: "And"` (the management-console default).
## Example
#### Allow Elevation Only for a Specific Signer
```json
{
"PolicyName": "Elevate Vendor X installers",
"PolicyType": "PrivilegeElevation",
"PolicyId": "example-policy-id",
"Status": "enforce",
"Operator": "And",
"Actions": {
"OnSuccess": { "Controls": ["ALLOW"] },
"OnFailure": { "Command": "" }
},
"Rules": [
{ "RuleName": "UserCheck", "RuleExpressionType": "BuiltInAction", "Expression": "CheckUser()" },
{ "RuleName": "MachineCheck", "RuleExpressionType": "BuiltInAction", "Expression": "CheckMachine()" },
{ "RuleName": "ApplicationCheck", "RuleExpressionType": "BuiltInAction", "Expression": "CheckFile(false)" },
{ "RuleName": "CertificateCheck", "RuleExpressionType": "BuiltInAction", "Expression": "CheckCertificate()", "ErrorMessage": "Certificate hash is not included in this policy" }
],
"UserCheck": ["*"],
"MachineCheck": ["*"],
"ApplicationCheck": ["*"],
"CertificationCheck": [
"A1B2C3D4E5F6..."
],
"DayCheck": [],
"DateCheck": [],
"TimeCheck": [],
"Extension": {}
}
```
This policy allows privilege elevation for any user, on any machine, for any application path — but only when the target binary is signed by the certificate matching the listed hash.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-reference/certificate-filter-certificationcheck.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
