Troubleshooting AS2
An AS2 exchange depends on settings held by both trading partners. A failure can occur before a message reaches its destination, while the recipient processes it, or when the sender validates the returned receipt. Identifying the stage and direction of the failure gives both teams a useful starting point for resolving it.
During initial setup, compare the identifiers, certificates, and delivery addresses agreed with your partner against the values configured at each end. Sending a file and accepting its Message Disposition Notification (MDN) are separate parts of the exchange, so a receipt error needs different investigation from a connection that never reaches the partner.
When a working connection stops, start with what changed and which direction is affected. Retain the error details and coordinate with the partner responsible for the receiving system. If transmissions succeed but the resulting files are duplicated or overwritten, investigate how the incoming files are handled rather than treating the issue as a connection failure.
This guidance is for administrators operating AS2 partnerships and resolving delivery problems with their trading partners. Use it to narrow the failure before changing settings, so a change addresses the actual problem without disturbing a working part of the exchange.
Problems Setting Up Your AS2 Identity
If an AS2 identity cannot be saved, compare the supplied values with the identity configuration requirements, then check the rejected field below.
| Issue | Resolution Steps |
|---|---|
| AS2 Identity, or Name, is not accepted. | Check whether another identity already uses that name, and enter a unique name. |
| My encryption/signing public certificate is not accepted. | Check that you supplied the complete certificate, including its beginning and ending lines, in PEM or CRT format. Confirm that it corresponds to the private key supplied for this identity. |
| My encryption/signing private key is not accepted. | Check that you supplied the complete private key in PEM or CRT format and that it matches the public certificate. If the key is password protected, confirm that the correct password was supplied with the import. A -----BEGIN ENCRYPTED PRIVATE KEY----- header identifies one password-protected format; it does not mean that the key is unsupported. The import requirements explain how to supply the password through the API. |
Problems Setting Up a Trading Partner
Problems configuring a trading partner are usually caused by an issue with the partner's public certificate.
| Issue | Resolution Steps |
|---|---|
| Trading partner public certificate is not accepted. | Confirm the certificate is in PEM or CRT format and includes the complete certificate, from -----BEGIN CERTIFICATE----- through -----END CERTIFICATE-----. |
Expiration alone does not prevent importing a trading partner's certificate. At Normal incoming signature validation, Files.com checks the signature and signed content without checking the certificate's validity dates. Use the displayed expiration date to coordinate renewal with your partner.
Trading Partner Having Problems Sending to Me
Several issues can cause incoming AS2 transmissions from your trading partners to fail:
| Issue | Resolution Steps |
|---|---|
| Incorrect URL being used. | Make sure your trading partner is sending the AS2 transmission to the correct endpoint URL. |
| Incorrect port being used. | Make sure that your trading partner is sending the AS2 transmission to port 443 of your Files.com site. |
| Incorrect AS2 trading partner Identity being used. | The trading partner is specifying an AS2 Identity that does not match your configuration. Make sure that the AS2 Identity that the trading partner is trying to use exactly matches the AS2 Identity that you specified for them. This is also known as the "AS2-From" header setting, which you can view in the AS2 Logs. |
| Incorrect AS2 Identity being used. | The trading partner has not specified your correct AS2 Identity. Make sure that the AS2 Identity being used by the trading partner to identify you exactly matches your AS2 Identity. If you have multiple AS2 Identities, then make sure that your trading partner is using the correct one. Check the configuration for the trading partner and confirm that the AS2 Identity shown in the My AS2 Name/Identity column matches what your trading partner is using. This is also known as the "AS2-To" header setting, which you can view in the AS2 Logs. |
| Trading partner is using an incorrect encryption certificate. | The trading partner uses your public certificate to encrypt AS2 transmissions to you. Make sure that the certificate they are using is exactly the same one as you imported in your AS2 identity. If you have multiple AS2 Identities, make sure that the trading partner is using the correct corresponding certificate. Resend the trading partner your correct public encryption certificate and verify that they are using it for AS2 transmissions to you. |
| You are using an incorrect trading partner signing certificate. | The trading partner uses their private certificate to sign AS2 transmissions to you. You will have received a corresponding public certificate from your trading partner. Make sure that the corresponding trading partner public certificate that you are using matches the public certificate that they provided you with. Check with the trading partner that the public certificate that they sent you corresponds to the private certificate that they are using to sign their AS2 transmissions to you. |
| Trading partner expects the AS2 Endpoint HTTPS TLS/SSL certificate to never change. | Occasionally, some trading partners configure their AS2 systems to save the SSL certificate fingerprint of the AS2 endpoint of their trading partners. Whenever the SSL certificate is updated, the fingerprint will no longer match, and further AS2 connections will not be allowed. This is sometimes referred to as "certificate pinning". Certificate pinning is not recommended, as it will disrupt AS2 transmissions every time the endpoint certificate changes. Your site's TLS/SSL certificate is used for your AS2 endpoint. By default, Files.com will automatically update your site's TLS/SSL certificates for you, prohibiting the ability to perform certificate pinning. You can implement your own custom TLS/SSL certificate provided that your site is configured with a Custom Domain. However, this certificate will be used by all of your site's services, not just your AS2 endpoint. Consider using a dedicated Child Site if you need a different TLS/SSL certificate for your AS2 service. Certificate pinning of the AS2 endpoint isn't recommended as it nullifies the practice of using fully valid and chained TLS/SSL Certificates. Pinning is typically used as a security workaround for when a trading partner implements a self-signed TLS/SSL certificate for their AS2 endpoint. |
| Trading partner is receiving unsuccessful HTTP response codes | A successful AS2 transmission will return a 200 response code. Other HTTP response codes will indicate the reason for the response. Codes such as 401 and 403 can indicate authentication or permission issues that need to be resolved. Codes such as 502 and 504 can indicate temporary networking issues caused by routers and gateway devices that reside on the network between sender and recipient. Properly configured AS2 systems automatically retry transmissions when these codes occur. |
Problems Sending to a Trading Partner
Several issues can cause outgoing AS2 transmissions to your trading partners to fail:
| Issue | Resolution Steps |
|---|---|
| Incorrect URL being used. | Make sure you are sending the AS2 transmission to the correct endpoint URL for your trading partner. Check with your trading partner that the endpoint URL is correct and not being blocked by firewall rules. |
| Invalid, expired, or untrusted SSL certificate is being used at the AS2 URL. | SSL certificates must be valid, chained, and trusted. Use an online SSL Certificate checker, such as SSL Shopper, to check the trading partner's AS2 URL and confirm that the SSL certificate is valid. If the trading partner is using an invalid, unchained, or self-signed SSL certificate, you can configure Files.com to allow this less secure connection by editing the trading partner entry and changing the Server certificate option to "Allow self-signed, unchained, expired, or non-matching TLS/SSL certificate". |
| Incorrect AS2 trading partner Identity being used. | You have specified an AS2 Identity that does not match your trading partner's configuration. Make sure that the AS2 Identity you are using exactly matches the AS2 Identity that they provided you with. This is also known as the "AS2-To" header setting, which you can view in the AS2 Logs. |
| Incorrect AS2 Identity being used. | You are not using your correct AS2 Identity. Make sure that the AS2 Identity you are using with the trading partner exactly matches the AS2 Identity that you provided to them. If you have multiple AS2 Identities, make sure you are using the correct one. Check the configuration for the trading partner and confirm that the AS2 Identity shown in the My AS2 Name/Identity column matches what you are using. This is also known as the "AS2-From" header setting, which you can view in the AS2 Logs. |
| You are using an incorrect partner encryption certificate. | Use your trading partner's public certificate to encrypt AS2 transmissions to them. Make sure that the certificate you imported for the trading partner is the correct one. The trading partner will have provided you with this certificate. Check with them that you have the correct one. |
| The trading partner is using an incorrect public certificate. | The trading partner uses your public certificate to verify the digital signature of your AS2 transmissions to them. You will have provided them with a public certificate that corresponds to your private certificate. Make sure that the public certificate you sent to the trading partner is the same one you used to configure your AS2 Identity. If you have multiple AS2 Identities, make sure you sent the trading partner the correct public certificate that corresponds to the AS2 Identity you are using with them. |
| The trading partner's AS2 system expects additional authentication. | When exchanging with Files.com, default AS2 authentication is set to Message Level Security. Configure a username and password for the trading partner if they also require Basic Authentication for the AS2 connection. |
Transmissions from My Trading Partner Have Stopped Working
When a previously working inbound transmission stops, the cause is usually one of the following:
| Issue | Resolution Steps |
|---|---|
| The trading partner has changed something on their side. | Contact the trading partner and find out what they changed. If they renewed, updated, or changed their AS2 certificates, ask them to send you their new public certificate. Re-import that certificate into the trading partner configuration. |
| You renewed, updated, or changed your AS2 certificates. | Confirm that you sent your trading partner your new public certificate. Contact the trading partner and verify that they are using your new public certificate for AS2 transmissions. |
Transmissions to My Trading Partner Have Stopped Working
When a previously working outbound transmission stops working, the cause is usually one of the following.
| Issue | Resolution Steps |
|---|---|
| The SSL certificate on the trading partner's AS2 endpoint URL has expired or is no longer valid. | Contact the trading partner and ask them to renew the SSL certificate on their AS2 endpoint URL. Use an online SSL Certificate checker, such as SSL Shopper, to check the trading partner's AS2 URL and confirm that the SSL certificate is valid. If the trading partner is using an invalid, unchained, or self-signed SSL certificate, you can configure Files.com to allow this less secure connection by editing the trading partner entry and changing the Server certificate option to "Allow self-signed, unchained, expired, or non-matching TLS/SSL certificate". |
| The trading partner has changed something on their side. | Contact the trading partner and find out what they changed. If they renewed, updated, or changed their AS2 certificates, ask them to send you their new public certificate. Re-import the new public certificate into the trading partner configuration. If they changed their AS2 endpoint URL, update the trading partner configuration with the new URL. |
| You renewed, updated, or changed your AS2 certificates. | Confirm that you sent your trading partner your new public certificate. Contact the trading partner and verify that they are using your new public certificate for AS2 transmissions. |
| File size is too big. | Outgoing messages are limited to 25MB in size. Files larger than this are not transmitted. |
Invalid or Badly Formatted MDN
An AS2 receipt contains a MIME multipart/report with a human-readable message and a message/disposition-notification part. A signed receipt wraps that report and a signature in multipart/signed, as defined in RFC 4130.
Open the returned MDN in the AS2 Logs. Check its MIME headers and boundaries, then the disposition-notification fields. For example, a successful disposition can contain:
Original-Message-ID: <message-id-from-the-original-transmission>
Disposition: automatic-action/MDN-sent-automatically; processed
Received-Content-MIC: <digest-of-the-original-message>, sha-256
This is an illustrative fragment, not a complete MDN. The message ID and Message Integrity Check (MIC) must correspond to the original transmission.
A message such as "The AS2 message has been received successfully" is only the human-readable portion. Correct MIME formatting and reassuring text do not establish a valid receipt. Files.com applies the partner's MDN validation level to the MIC, disposition, signature, and certificate as applicable.
Some partner systems return an HTML error page or raw processing error instead of an MDN. Give your trading partner the returned error, HTTP status, transmission time, and message ID so they can investigate the endpoint or downstream processing failure. If the structure is valid but signature validation fails, see Incorrectly Signed MDN.
Inbound Files Are Overwritten
If an incoming file replaces an earlier delivery unexpectedly, compare your site's Overwrite Behavior setting with the incoming filename rules. Confirm whether your trading partner is reusing the same filename.
Verify that the Overwrite Behavior setting hasn't been changed. The Settings Changes log shows when the setting was changed and by whom.
Duplicate Inbound Files
If an AS2 inbox contains more copies of a file than you expect, compare the saved names with the filenames sent by your trading partner. The incoming filename rules explain how overwrite and renaming settings handle repeated names.
Check the site's Overwrite Behavior setting and any Rename Uploaded Files setting on the partner's inbox folder. Renaming can retain separate deliveries under different names, even when the partner sends the same filename each time.
Review the AS2 Logs to compare the incoming transmissions with the files in the inbox. This helps distinguish repeated deliveries from a difference between the filenames your partner sent and the names saved in Files.com.