> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/verificacion-de-firmas/procedimientos-de-verificacion.md).

# Verification procedures

Once the configuration described above has been carried out, Editran/FF provides the following two methods for validating signatures:

1. If the application for which the purpose *Verify signatures* has an associated user of type *Local*, it will be accessed with it to *UserFF*. The verification of an application's signatures takes place every time the right panel list is refreshed because the branch *Applications*, the branch *Signature Verification* or the branch associated with the different users of type *Remote* linked to the application. As already mentioned, in the applicable signature modes, during verification the signed files are extracted to the directory *Files* *received*. When the verification process ends, the column *Status* in the list shows its result, either at application level or at file level with respect to the user. Every time the Summary of an application is consulted for *Verify signatures,* through the corresponding button on the taskbar, the application's set of signatures is also validated. In this case, the dialog displayed includes both the application status and the status of each file as a whole and of each file with respect to each particular user. The **verification** of the signatures from *UserFF* is **manual** and may be useful for testing or, when in production, to visually analyze the reason for a verification that ended in error.
2. To perform the **verification** of the signatures in an **automatic**, calls will be made from a batch to one of the following two commands: *EstadoApl.exe* or *XAdES.exe*. Both programs are located in the Editran/FF installation directory. To find out the result code returned by these commands, run:

*echo %ERRORLEVEL%*

immediately after the command execution. The product user will decide what behavior should be followed according to the result obtained.

Specifically, one of the following two executions will be carried out:

* *EstadoApl \[Editran/FF application name]* This command checks the signatures found in the application's directory *Signatures* . The result it returns is the application status, that is, the status of the set of files and signatures. The possible statuses of an Editran/FF application are described in section **5.5** of this manual.
* If the signatures to be verified are in any of the XAdES modes, verification can also be done signature by signature, by running:

*XAdES –FF\[Editran/FF application name] –V –F\[signature file name]*

**Following –F, only the file name needs to be entered**, the command searches for the file in the signature directory indicated in the application, so the full path should not be written.

The possible result codes returned by XAdES.exe are described in section **7.10** of this manual.

During the verification process carried out from XAdES.exe, if no error prevents it, a file is written with the same name as the signed one plus the extension *.ctrl,* in a subdirectory called *TMP.XD* under the directory *Received files*. That file contains a first line with a result code and a diagnosis of the verification and, below that, successive lines with the DN of the certificates with which the signatures were made. Each of the lines with the DN is preceded by an S if that DN corresponds to one of the Remote type users associated with the application, or N otherwise.

If the verification ends in error and the first line of the file *.ctrl* is not sufficiently descriptive, it is recommended to consult the XAdES\logs\out.log log to obtain detailed information about the problem.


---

# 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.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/verificacion-de-firmas/procedimientos-de-verificacion.md?ask=<question>&goal=<user_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.
