MFT Gateway Inbound Message Failures

Inbound failures occur when the MFT Gateway, as the recipient, successfully received a message but could not be processed because a matching partner entity could not be found.

Identification/correlation Issues

The AS2 protocol relies on the AS2-From and AS2-To headers to route messages to the correct logical entities. If an incoming message contains identifiers that do not match the stations or partners in the MFT Gateway account, the system cannot correlate the message.

Possible Symptoms and Error Messages

MFT Gateway returns an HTTP 422 error code (Unprocessable request) to the partner, with the body detailing the error; unable to find the partner with identifier: <AS2-Identifier>. These messages can be found in the failure inbound message table view.

Steps to resolve:

Check whether the sender is already registered as a partner in your MFT Gateway account. If they are, compare the AS2-From transport header in the incoming request with the AS2 identifier configured in the partner profile. Mismatches can occur due to case sensitivity or the use of legacy identifiers following a system migration.

Decryption Failures

During sending, the message is encrypted using your MFT Gateway station public key/certificate as available to the partner (so that MFT Gateway can decode/decrypt the message, using the corresponding station’s private key). Some common scenarios can cause this encrypted message unreadable to the MFT Gateway.

Incorrect public key

If the partner uses an incorrect certificate to encrypt the message, the corresponding station’s private key will fail to decrypt the payload.

Possible symptoms and error messages

In this scenario, MFT Gateway as the recipient produces a negative MDN like below.

Steps to resolve:

Share the certificate configured for the MFT Gateway station with the partner and ask them to recheck if the same certificate is configured on their system to encrypt the messages. The combination ({Issuer’s distinguished name (DN)}, {certificate’s serial number}) must match on both ends. But usually checking the serial number is sufficient.

Certificate Rotation

If the station certificate has been rotated/renewed and the corresponding partner is still using the outdated public key to encrypt the messages, a decryption failure can occur at the MFT Gateway side.

Possible symptoms and error messages

MFT Gateway produces a negative MDN with the same error as the earlier issue.

Steps to resolve:

If the MFT Gateway station certificate is rotated (renewed after/close to its expiry), all the corresponding partners must be updated with the new public certificate.

Note that MFT Gateway has a built-in certificate expiration alert mechanism to help detect upcoming expirations of station and partner certificates. If you receive an alert for a partner certificate expiration, it is best to reach out to the partner to obtain the updated public certificate.

Payload Corruption

Generally if the AS2 payload (HTTP request body) is damaged or truncated during transmission, decryption will fail at the MFT Gateway as the receiver end. (Even in the unlikely, rare chance of decryption being successful, signature verification is guaranteed to fail later in the process.)

Possible symptoms and error messages

In this scenario, MFT Gateway as the recipient produces a negative MDN like below.

Steps to resolve:

You can compare the Content-Length header with the actual number of bytes received to confirm that the payload was corrupted during transmission.

Signature Verification and Trust Anchors

During sending, your partner signs the message using their own private key, so that the MFT Gateway can verify the integrity of the transferred content/file, using the partner’s public key/certificate, and authenticate that it actually came from the claimed partner. This process can fail due to several reasons:

Untrusted Certificates

Usually, if the issuer/trust chain of partner’s certificate is not available in the MFT Gateway trust store, MFT Gateway would refuse to trust the signature generated by the partner - causing the verification to fail.

In case the partner’s certificate is self-signed, whereby the issuer is the same as the subject, a copy of that certificate itself needs to be present in the MFT Gateway trust store.

Possible symptoms and error messages

In this scenario, MFT Gateway as the recipient produces a negative MDN like below.

Steps to resolve:

Import partner’s certificate (if self-signed), or a sufficient portion of its issuer chain, to the MFT Gateway certificate store - in order to complete the trust chain. For example, if the partner’s certificate chain is sender -> issuerA -> issuerB -> issuerC and MFT Gateway certificate store already has issuerB, adding just issuerA would complete the chain.

Incorrect signature verification certificate

Signature verification will fail if the AS2 partner is configured with an incorrect certificate, or if the partner requires a separate certificate for signature verification that differs from the one used for encryption.

Possible symptoms and error messages

In this scenario, MFT Gateway as the recipient produces a negative MDN like below.

Steps to resolve:

Confirm with the partner and assign their correct certificate as the verification certificate to the corresponding MFT Gateway partner profile. If the partner requires a separate certificate for signature verification, update your partner accordingly.

Message Digest Mismatch

Partner’s signature contains a digest/hash of the original content/file. MFT Gateway calculates the digest over the same content and if these two digests do not match, MFT Gateway cannot trust the integrity of the content that they got after decoding.

Possible symptoms and error messages

In this scenario, MFT Gateway as the recipient produces a negative MDN like below.

Steps to resolve:

• This could indicate that the content was actually tampered/corrupted by a third party. In such cases, partner may need to refresh their certificate/key material (and share the new public certificate again to their recipients), because the current ones may most probably have been compromised.
• In some cases, encoding issues (e.g. type of line endings in original vs. decoded content) can lead to digest mismatches, even for untampered content. In this scenario, the MIME content encoding parameters, such as Content-Transfer-Encoding, must be rechecked and compared on both the partner and MFT Gateway ends.