Troubleshooting Signature Verification Errors

ESIG-101

'Signatures (Raw)' field is missing or corrupt. An error occurred while reading or parsing the raw signature data field of this record.

Verify that the record type in QC/ALM has a field named "Signatures (Raw)". This is where the electronic signature information is expected to be stored.

Verify that "Signatures (Raw)" field of the associated record is not corrupt. It should contain valid JSON-formatted data.

Verify that QC/ALM has not unexpectedly reformatted this field as HTML.

NOTE: It is often necessary to verify the contents of this field with reporting from the Analysis View or directly from the database view in the QC/ALM Site Administration portal.

If the record type is not expected to contain signatures, then update the project's Records Management Policy to exclude this record type from signature verification.

If the record type is expected to contain signatures, but the "Signatures (Raw)" field is missing, then update the template configuration to add a "Signatures (Raw)" memo field to the corresponding item type.

If the "Signatures (Raw)" field has become corrupted, then if possible, manually correct the corruption. If that is not possible, then manually purge the "Signatures (Raw)" field, and have the record re-approved with new signatures.

ESIG-102

Missing signature component. A required data element is missing from the signature.

The detailed error message should indicate the specific data element that is missing. Inspect the JSON-formatted signature information in the "Signatures (Raw)" field to determine whether the element is missing or otherwise corrupted.

Verify the audit history of the field to determine whether any unexpected modifications to the signature data were made outside of the system's expected use.

If unexpected modifications were made to the "Signatures (Raw)" field, then attempt to revert those modifications.

If that is not possible, then manually delete the impacted signature from the "Signatures (Raw)" field, and have the record re-approved with new signatures.

ESIG-103

Signature hash failure. The electronic signature has been modified or corrupted, and it is no longer authentic.

Verify the audit history of the field to determine whether any unexpected modifications to the signature data were made outside of the system's expected use.

If unexpected modifications were made to the "Signatures (Raw)" field, then attempt to revert those modifications.

If that is not possible, then manually delete the impacted signature from the "Signatures (Raw)" field, and have the record re-approved with new signatures.

ESIG-104

Invalid record association. The electronic signature was generated for a different record than the record it is currently associated with.

Verify whether this is an original record. This error most typically occurs when a record is duplicated (within the same project), and its signature data is inappropriately duplicated with it.

If the signature was duplicated from another record, then manually purge the signature from the current record.

If the signature was moved from another record, then manually move it back to its intended location.

ESIG-105

Record hash failure. The signature does not match the current contents of the record. The record has been modified after the signature was applied.

Inspect the record's audit history. A field that is configured as a data field (as opposed to a metadata field) was modified after this signature was applied.

NOTE: This error will only be reported for active signatures. The record hash will not be verified for inactive signatures (as it is expected that a record can change after a signature is removed).

If the record was unexpectedly modified, then attempt to manually revert the modifications.

If that is not possible, or if it is undesirable, then revise the record and route it for new signatures.

Invalid signature transport. The active signature was generated in another project/repository, and it is not valid for the current record. Either the record was modified after the transport, or the signature has become associated with a different record.

This error indicates that the signature cannot be associated with the current record, but the exact reason cannot be determined because the signature was transported from another location. This can most likely happen if a signed record is imported from a QC/ALM library, and the record is unexpectedly modified after the import; or it can happen if data loss/corruption occurs during a data migration operation.

Inspect the record's audit history to determine if any unexpected modifications were made while the signature was active.

Inspect the signature information to determine the original location of the signed record. Determine whether any data field differences exist between the original location and the current location. (For example, the new location is missing important data fields that existed in the original location.)

If the record was unexpectedly modified, then attempt to manually revert the modifications.

If data field differences exist between the record's original location and the new location, then update the new location so that it has all of the same data fields (at a minimum) as the original location.

If data value differences exist between the record's original location and the new location, then update the new location to contain the same values as the original.

If the signature has become associated with the wrong record, then manually purge signature or restore it to its correct location.

If none of the above are possible or desirable, then revise the record and route it for new signatures.

ESIG-201

'Signatures' field is missing or corrupt. An error occurred while reading or parsing the displayed signature data field of this record.

Verify that the record type in QC/ALM has a field named "Signatures". This is where the displayed (human-readable) signature information is expected to be stored.

Verify that "Signatures" field of the associated record is not corrupt. It should contain plain text signatures.

Verify that QC/ALM has not unexpectedly reformatted this field as HTML.

NOTE: It is often necessary to verify the contents of this field with reporting from the Analysis View or directly from the database view in the QC/ALM Site Administration portal.

If the record type is not expected to contain signatures, then update the project's Records Management Policy to exclude this record type from signature verification.

If the record type is expected to contain signatures, but the "Signatures" field is missing, then update the template configuration to add a "Signatures" memo field to the corresponding item type.

If the "Signatures (Raw)" field has become corrupted, then if possible, manually correct the corruption. If that is not possible, then manually purge the "Signatures" field, and have the record re-approved with new signatures.

ESIG-202

Displayed signature is corrupt. The displayed signature could not be parsed.

A displayed signature is not formatted as expected. Inspect the contents of the Signatures field to determine whether each signature is displayed in a standard format.

If unexpected modifications were made to the "Signatures" field, then attempt to revert those modifications.

If that is not possible, then manually delete the impacted signature from the "Signatures" field, and have the record re-approved with new signatures.

ESIG-203

No corresponding signature data. The displayed signature has no corresponding electronic signature data and cannot be verified.

Verify the audit history of the "Signatures" and "Signature (Raw)" fields to determine whether any unexpected modifications to the signature data were made outside of the system's expected use.

Verify whether the data in the "Signatures" field may have been imported from another project or system without the corresponding signature data.

If unexpected modifications were made to either the "Signatures (Raw)" or "Signatures" fields, then attempt to revert those modifications.

Otherwise, manually delete the impacted signature from the "Signatures" field, and have the record re-approved with new signatures.

ESIG-204

Signature text has been modified. The displayed signature does not match its hash information. The displayed signature is no longer authentic.

Verify the audit history of the "Signatures" and "Signature (Raw)" fields to determine whether any unexpected modifications to the signature data were made outside of the system's expected use.

If unexpected modifications were made to the "Signatures" field, then attempt to revert those modifications.

If that is not possible, then manually delete the impacted signature from the "Signatures" field, and have the record re-approved with new signatures.

ESIG-301

eApprove - Signature hash failure. The electronic signature created by eApprove has been modified or corrupted, and it is no longer authentic.

This error implies an expected change made to the AUDIT_LOG table where the eApprove signature data is stored. Investigate system activity and research the system history to determine whether any activities have occurred that may have impacted the AUDIT_LOG table.

If a backup of the project exists prior to the corruption, then the impacted AUDIT_LOG entry might be recoverable from the backup.

Otherwise, the corrupted entry must be removed from the AUDIT_LOG. If the signature is active, then it must also be deleted from the Signatures field, and the record must be routed for new signatures.