> 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/configuracion.md). # Configuration To verify the received signatures, it is necessary for the validating end to perform with *AdminFF* the corresponding configuration: users of type *Remote* associated with applications whose purpose is *Verify Signatures*. In general, if the signing end has the Editran/FF product, an application to *Verify signatures* will be a reflection, a mirror, of the application to *Sign* used by the issuer of the signatures. And the same happens with users of type *Remote* of the validating end with respect to those of type *Local* of the signing end. As seen in this manual, in an application to *Sign,* users of type *Local* are those who perform the signatures and, in an application to *Verify*, users of type *Remote* are those whose signatures are to be verified. That is, for each user of type *Local* on a signing end, there will be a user of type *Remote* on a signature-validating end. One and the other will have the same information regarding the certificates in the profiles. Therefore, before starting to create the configuration of the users *Remotes* and of the applications to *Verify* *signatures*, the signing end must send the following information to the validating end: * The DN and the rest of the certificate information needed for configuring users of type *Remote* of Editran/FF * The signature mode that was used * The format of the files that are signed * Complete description of the type of signature validation needed that is being applied: users, groups or joint rules. These are the steps to be carried out: 1. The signing end will send to the receiving and validating end of its signatures the information relating to the certificates with which they are made. It can do so in two ways: by sending the public part of each certificate (exporting the certificate with .cer extension) or, if the signing end has Editran/FF Windows, it can also obtain that information with *EnviarDN.exe*. Once the validating end has this information, it must incorporate it with *AdminFF* to users of type *Remote.* 2. The validating end will configure the applications with purpose *Verify signatures*, completing all the fields in the dialog, such as the signature mode corresponding to the signatures to be received (the signing end will have informed it), the format of the signed files, etc. The directory *Signatures* indicated (second tab of the directories table) is the one where Editran/FF will look for the signatures of the application it is going to verify. Therefore, **in the directory *****Signatures***** must be the same before starting verification.** On the other hand, to describe the contents of the directory *Received files* (first tab of the directories table) it is necessary to take into account the signature mode of the application: * Modes in which **the signature includes the data file** (PKCS#7 Attached, Xades Detached Internal Implicit, etc.): this is the directory to which the files contained in the signature are extracted during the verification process. Therefore, **in these signature modes before starting verification, the directory *****Files*** ***received***** will be empty.** * Modes in which **the signature does not include the data file** (PKCS#7 Detached, Xades Explicit - except XAdES Detached Internal Explicit One File -, etc.): if any of these modes is used, the signing end must send both the data files and the signatures. Therefore, ***in these signature modes,*** ***the data files corresponding to the signatures must be in the Received files directory before*** ***starting verification.*** 3. The users of type *Remote* corresponding to the certificates whose signatures are to be verified will be associated with each application. Optionally, in order to be able to perform the validation of the signatures manually, as will be described later, it is advisable to also associate a Local type user with the application. In general, the signature validation system required by these applications will be a replica of the system used by the signing end to validate its own signatures and that it has previously reported: users, groups or joint conditions. In this way, the receiver can verify that the validation criterion established by the issuer has been maintained all the way through. For example, if the signing end has defined that each file of an application must have two signatures that can be made by any two signers out of three possible ones, and for this it establishes a group of three local users with two required signatures, the receiving and validating end will define that same group with the corresponding remote users (those associated with the same DNs as the Local type users of the signing end) and with the same number of required signatures. In an application whose purpose is *Verify signatures,* will be marked *Enablement -> Yes* only if the signing end is going to send the enablement file together with the signatures, and *Enablement -> No* otherwise. **If *****Enablement -> Yes*****, necessarily the name of the application to *****Verify signatures***** must match the name of the application to *****Sign***** of the issuing end (the application alias is part of the name of the enablement file).** Likewise, **if the signature mode used is PKCS#7 Detached, the aliases of the local users of one end and the remote users of the other must also match (in this signature mode, the user alias is part of the name of the signature file)**. Except for the two situations mentioned, the aliases or names of the users of type *Remote*, of the applications for *Verify* and of the groups of the verifying end do not have to match those of the signing end. --- # 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/configuracion.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.