Troubleshooting Common Errors

This page provides a list of common errors that may be encountered while using Arc, the likely cause of these errors, and how to resolve them. These errors are grouped together based on similar contexts in which they arise, but these groupings may not hold true in all cases. As a result, it may be easiest to search the page for the text for a given error.

If you are encountering an error that is not listed below, please reach out to our support team at arcsupport@cdata.com.

• AS2 Errors
  • The receipt signature could not be verified: Message digest mismatch in signature
  • The receipt signature could not be verified: The certificate specified does not match the signature
  • The receipt signature could not be verified: Message digest was encrypted with unknown algorithm
  • MDN Error: Authentication failed
  • MDN Error: Signature Authentication failed: Could not authenticate signer’s identity
  • MDN Error: Unexpected processing error
  • Incoming request did not match a configured trading partner profile
  • Synchronous MDN expected but not received
  • Unsigned MDN received, but signed MDN requested
• Connection Errors
  • System error: Connection refused
  • Connection time out
• HTTP Errors
  • 500 Internal Server Error
  • 400 Bad request
  • 404 Not Found
  • 401 Unauthorized
  • 403 Forbidden
  • 504 Gateway Timeout
  • SSL/TLS Errors
  • Error during handshake: The token supplied to the function is invalid
  • Error during handshake: the buffer supplied to a function was too small
  • Error during handshake: the function requested is not supported
• General Certificate Errors
  • Unable to find valid certification path to requested target
  • Key does not exist
  • Cannot open certificate store: The specified network password is not correct. (0x56)
  • The receipt signature could not be verified. Signature is not valid!
• EDI Errors
  • Schema file not found
• Miscellaneous Errors
  • Input string was not in a correct format

The following errors come up primarily in the context of AS2 connections. Often these related to AS2 protocol details like MDN receipts.

Cause

MDN receipt signatures contain a message digest that ensures the content of the message has not been altered in transit. A digest mismatch could suggest that the MDN was altered before being received, or was not generated properly on the partner’s end.

Resolution

First, examine the MDN returned by the partner for apparent issues. The MDN can be accessed by downloading the full logs for the transaction where this error occurred (in the Input tab of an AS2 Connector or in the Transaction log).

The Arc support team can take a look at MDNs for which this error is thrown if the issue is not immediately apparent. Additionally it may be necessary to reach out to the trading partner to confirm how the MDN digest was calculated.

Cause

MDN receipts are signed using a digital certificate to ensure that they come from the expected party. This error indicates that the certificate configured in Arc could not be used to verify this digital signature. This typically indicates a certificate mismatch, where the appropriate certificate(s) are not configured on one side of the connection.

Resolution

To resolve certificate mismatch errors, confirm that each partner has exchanged public certificates and that these certificates are correctly configured on each end. Within Arc, the public certificate for a trading partner should be configured in the AS2 Connector for that partner under the Encryption Certificate field.

Some partners use separate certificates for signatures than they do for encryption/decryption, in which case you may also need to set the Partner Signing Certificate in the Advanced tab of the AS2 Connector.

Private certificates are configured in the AS2 Profile, and should never be shared with trading partners.

If the certificates are correctly configured in Arc, confirm with the trading partner that they have also configured your public certificate correctly.

Cause

This error indicates a known issue in older versions of the application that only supported SMIME encryption v3.1. If an MDN contains a message digest encrypted with SMIME 3.2, this error will be thrown.

Resolution

All current versions of Arc support SMIME 3.2. RSSBus Connect 2016 was the last version known to have this issue, and it was resolved in the final archived builds of RSSBus Connect 2016. Older versions will require an upgrade to resolve this error.

Cause

This error is included as part of the MDN response, indicating that the trading partner could not verify the signature in the AS2 request. This suggests a general certificate mismatch between the trading parties.

Resolution

To resolve certificate mismatch errors, confirm that each partner has exchanged public certificates and that these certificates are correctly configured on each end. Within Arc, the public certificate for a trading partner should be configured in the AS2 Connector for that partner under the Encryption Certificate field.

Some partners use separate certificates for signatures than they do for encryption/decryption, in which case you may also need to set the Partner Signing Certificate in the Advanced tab of the AS2 Connector.

Private certificates are configured in the AS2 Profile, and should never be shared with trading partners.

If the certificates are correctly configured in Arc, confirm with the trading partner that they have also configured your public certificate correctly.

Cause

This error is included as part of the MDN response, indicating that the trading partner could not verify the signature in the AS2 request. This suggests a general certificate mismatch between the trading parties.

Resolution

To resolve certificate mismatch errors, confirm that each partner has exchanged public certificates and that these certificates are correctly configured on each end. Within Arc, the public certificate for a trading partner should be configured in the AS2 Connector for that partner under the Encryption Certificate field.

Some partners use separate certificates for signatures than they do for encryption/decryption, in which case you may also need to set the Partner Signing Certificate in the Advanced tab of the AS2 Connector.

Private certificates are configured in the AS2 Profile, and should never be shared with trading partners.

If the certificates are correctly configured in Arc, confirm with the trading partner that they have also configured your public certificate correctly.

Cause

This error is thrown by the trading partner’s system and is returned as part of the MDN to indicate a failure to process the AS2 request. This error is a general error, thrown when the problem is not related to signing, encryption, or compression.

Resolution

Since this error does not include specific debugging information, contact the trading partner to learn more about what caused the failure in their AS2 processing system.

Cause

When an AS2 message is received by Arc, the application attempts to route the message to a specific AS2 Connector based on the configured AS2 identifiers. This error indicates that no connector could be found where the AS2 identifiers for sender and receiver match the values present in the AS2 message.

Resolution

Check the AS2 identifiers configured in both the AS2 Profile section of Arc and the AS2 Connector configured for the specific trading partner affected by this error.

Cause

This is a general error indicating that the response to the AS2 request was not an MDN. This may indicate that the AS2 request was not sent to an AS2 server as expected. This error can also be thrown if an MDN was returned, but it was corrupted such that Arc cannot appropriately recognize it as an MDN.

Resolution

Check that the target URL is correct. Then, check to see if a firewall may be stripping contents from the MDN, preventing Arc from parsing it correctly. If the issue with the MDN is not clear, find the .mdn file associated with the failed transaction and investigate further.

Cause

When Arc receives an MDN receipt from a trading partner, the first step in processing this MDN is verifying the digital signature. This error indicates that the process of finding this signature failed; either because the signature/MDN was not generated correctly or because the response being treated as an MDN receipt is not actually an MDN.

Resolution

Examine the MDN being received from the trading partner; the MDN can be accessed by downloading the full logs from the failed transmission. Often, the MDN file will not actually contain an MDN but rather some HTML error page indicating something that went wrong during the AS2 transmission.

If the MDN looks correct (i.e. looks like a normal MDN), inform your trading partner that you were unable to process the MDN they generated, and see if they have input on what might have gone wrong during the generation of the MDN.

These errors relate to the basic connection established in most network transmissions.

Cause

This network error indicates a general connectivity problem. It is thrown when a connection attempt is made to a server that is not actively listening. This may indicate the server has gone down, or that the connection attempt is being made to the wrong URL/port.

Resolution

Check that the target URL and port is correct. If the error persists, contact the server administrators for the target system to see if the server has gone down, or if they have more information about the issue.

Cause

This network error indicates a general connectivity problem. It is thrown when the connection attempt to the server goes unanswered for a period of time (default 60 seconds). This is often the result of firewall interference, but it may also indicate incorrect connection parameters.

Resolution

First, confirm that the basic connection parameters (remote host, port, URL, etc) are correct.

Then, check that any relevant firewalls are allowing traffic to flow between the client and server. Often this involves whitelisting the client’s IP address on the firewall protecting the server. Some firewalls may also need to be configured to allow outbound traffic, but blocking inbound traffic is much more common.

Note: the error message for this issue can also be the following:

Connection failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

These errors relate to the processing of an HTTP request, and may be relevant for any protocols built on top of HTTP (like AS2).

Cause

This HTTP error indicates a general server-side failure. The connection was successfully established, but some error occurred at the HTTP processing level and no further debugging information is immediately available.

Resolution

Since this error does not provide debugging information, it is necessary to contact the remote trading partner to check for server-side logs providing context to the failure. These logs should provide information to find the root cause of the issue.

Cause

A 400 Bad Request error indicates that the server-side believes the inbound request is malformed in some way. Often this is a result of incorrect or missing headers, or unexpected data in the HTTP body.

Resolution

Since the server is complaining about the request from the client, the server-side is likely to have additional debugging logs with additional information about the failure. This may be an indication that additional connection requirements are in place for this server, like a requirement for HTTP authentication headers. The server-side administrator should confirm whether such requirements are relevant and thus can be configured in the connector making the outbound request.

Cause

This HTTP error indicates that no resource could be found at the target URL. This usually indicates that the first half of the URL is correct (host, port) but that the second half of the URL (the resource path) is not recognized.

Resolution

Check that the resource path in the target URL is correct. It may be worth confirming with the trading partner what the expected resource path should be.

Cause

The HTTP 401 Unauthorized error indicates that the resource being requested requires additional authentication. This may be the result of attempting to access the wrong URL (i.e. sending a request to a sensitive endpoint on the server rather than the publicly-accessible endpoint), or it may indicate that the HTTP request needs to be updated with authentication parameters.

The likely types of authentication required are SSL Client Authentication and HTTP Authentication, both of which are available in the Advanced tab of the AS2 Connector.

Resolution

Check that the target URL is correct. If so, update the appropriate client authentication details in the connector sending the request. This likely will be one of either SSL Client Authentication or HTTP Authentication, both of which are sections in the Advanced tab of the configuration panel.

Cause

The HTTP 403 Forbidden error indicates that the remote server recognizes who is sending the request, but that this client does not have access to the resource being requested. This may be the result of targeting the wrong URL (i.e. sending a request to a sensitive endpoint on the server rather than the publicly-accessible endpoint), or a lack of a permissions established on the server-side to provide access for the client.

Resolution

First, check that the target URL is correct. If so, check with the remote server to see if additional permissions need to be granted to the client, or if some part of the request is unsupported such that the server is denying access. This issue can only be addressed from the server-side.

Cause

This error indicates an issue on the server side where the router/firewall or some other network gateway entity encountered an issue. This gateway is responsible for forwarding inbound requests to its final destination for processing. In this case, the gateway did not receive a response from the target destination, so the timeout error is relayed back to the client.

Resolution

This issue can only be debugged from the server-side; contact the remote server to confirm that their network traffic is flowing as expected.

The following errors occur at the SSL/TLS level for basic transport security.

Cause

This is one of several SSL errors returned by the WinSock library (Windows Sockets). Often, this error occurs when an HTTP connection is attempted with a server that expects HTTPS connections.

Resolution

Confirm with the trading partner whether the AS2 connection should be over HTTP or HTTPS, and check that the target URL has the appropriate prefix and port. Arc detects whether to negotiate SSL based on the prefix for the URL; an ‘https’ prefix will tell the application to negotiate SSL, while an ‘http’ prefix indicates a plaintext connection.

Cause

This is one of several SSL errors returned by the system WinSock library, and is a known bug with the Windows CryptoAPI on certain server OS’s. The issue occurs when using TLS 1.2 and two specific cipher suites:

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
RLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Resolution

These ciphers can be disabled at the OS level using third-party cryptography tools (i.e. programs that allow security configuration of the OS’s cryptography libraries).

Arc also includes an internal implementation of these cryptographic operations, and this managed implementation can be enabled to bypass the Windows CryptoAPI limitation. Note that this will cause an application-wide change in the way that cryptography is managed, so perform this configuration change with caution.

To enable the managed implementation, edit the following line to the profile.cfg file (in the application’s Data Directory) to set the property to ‘true’:

UseManagedSecurityAPI = true

Cause

This is one of several SSL errors returned by the system WinSock library, and indicates a mismatch in the supported SSL/TSL versions between client and server.

Resolution

SSL/TLS versions can be enabled within the Advanced tab of the connector sending the request. Confirm with the trading partner which of these SSL/TLS versions should be enabled, and disable all non-supported versions.

The following errors relate to accessing certificates across many different contexts in Arc.

Cause

This error is thrown in the Java edition by the underlying Java security provider. It indicates that the SSL server certificate presented by the target web server is not trusted by the system.

Resolution

The SSL Server Certificate trust can be overridden in the AS2 Connector by setting the Trading Partner Certificates -> SSL Server Certificate setting to the server’s public key certificate (or to ‘Any Certificate’). The server’s certificate can be acquired by connecting to the web server through most modern web browsers, though this is outside the scope of Arc specifically.

Setting this property to ‘Any Certificate’ implicitly trusts the identity of the server and bypasses the certificate check.

Cause

This is a known issue in the Windows CryptoAPI when multiple threads are attempting to access the same private key. By default, Arc uses the Windows CryptoAPI to perform security operations like loading private certificates.

Resolution

Arc comes with an internal implementation of crypto operations, and this managed implementation can be enabled to workaround the Windows CryptoAPI limitation. To enable the managed implementation, add or edit the following line in the port.cfg file (in the folder for the relevant connector within the ‘data’ or ‘workspaces’ directory):

CertUseManagedSecurityAPI = true

Cause

This error typically occurs when the password for the private key certificate (.pfx) in the AS2 Profile is incorrect.

Resolution

Navigate to the profile page in the application, enter the certificate password, and attempt to ‘Save Changes’. If a red dialogue bar appears with this error message, it indicates that the application is unable to access the certificate due to the password being rejected. Confirm the correct password for this certificate and update the configuration accordingly.

Cause

This error indicates that the trading partner is returning an MDN with an invalid signature. This could mean the signature is not present at all, or that the signature was generated using an unexpected signing algorithm, or some other issue occurred during the signature generation.

Resolution

First, examine the MDN returned by the partner for apparent issues. The MDN can be accessed by downloading the full logs for the transaction where this error occurred (in the Input tab of an AS2 Connector or in the Transaction log).

The Arc support team can take a look at MDNs for which this error is thrown if the issue is not immediately apparent. Additionally it may be necessary to reach out to the trading partner to confirm how the MDN signature was generated.

The following errors occur in EDI Connectors like X12 Connectors or EDIFACT Connectors.

Cause

EDI connectors (e.g. X12, EDIFACT) use schema files to parse EDI documents according to the appropriate EDI standard. This error indicates that Arc could not find the schema file for the particular document type being processed.

Resolution

Arc provides extra EDI schemas for free here. Find the appropriate EDI version and download the relevant schema files. Then place these schemas at one of the following locations below:

Windows: C:\Program Files\CData\Arc\www\app_data\[EDI-standard]_schemas
Java (embedded server): /opt/arc/Schemas/[EDI-standard]_schemas
Java (external server): {webapp_path}/WEB-INF/[EDI-standard]_schemas

Cause

This indicates that string validation failed for some aspect of the AS2 Connector configuration. Typically the Receiving URL setting or or some string processing in the Events scripts are the source of the error.

Resolution

Check that the target URL in ReceivingURL begins with a valid HTTP prefix (‘http://’ for plaintext connections or ‘https://’ for SSL connections) and does not contain any unintended whitespace.

If scripts are present in the Events of the connector (e.g. BeforeSend, AfterReceive) then check for string processing for which invalid input might be provided.