Search

AS2 Connector

Version 22.0.8473

AS2 Connector

The AS2 Connector supports sending and receiving messages via the secure and reliable AS2 protocol.

Overview

An AS2 connection is configured in two places. The AS2 Profile section should be configured with a local AS2 identifier, private certificates, and other information that is global among all AS2 connections. Then, each AS2 Connector should be configured with connection settings specific to a single trading partner. When an input file is processed by an AS2 Connector, it is packaged and sent to the specified trading partner.

When CData Arc receives a file over AS2, it attempts to route the file to a specific AS2 Connector. The application uses the AS2 identifiers in the AS2 message to determine which AS2 Connector should receive the file. When a file is routed to an AS2 Connector, that file is placed in the connector’s Receive directory, or is passed along to the next connected connector in the flow.

AS2 Connectors support all of security and reliability mechanisms that make AS2 a popular protocol. An explanation of the AS2 protocol exchange and an explanation of the certificates used for AS2 security can be found below.

Profile Configuration

The AS2 Profile must be configured before connections can be established with individual AS2 Connectors.

AS2 Profile Tab

Personal Id

Settings for identifying the local profile.

  • AS2 Identifier Your AS2 identifier. Messages sent by Arc will include this value as the ‘AS2-From’ header. Incoming messages must have this value set as the ‘AS2-To’ header to be successfully received. AS2 Identifiers are case-sensitive.

Personal Certificate

Settings related to the private decryption and signature certificate.

  • Private Certificate The certificate that will be used to decrypt incoming messages and sign outgoing messages. This certificate should never be shared with any external parties. Click the Create Certificate button to generate a new self-signed certificate that is ready to use in an AS2 transaction; a corresponding public key will also be generated with the same filename and a ‘.cer’ extension.
  • Certificate Password The password required to access the Private Certificate.
  • Rollover Private Certificate A secondary private certificate that can be used to decrypt incoming messages if decryption with the Private Certificate fails. This setting should be used only when transitioning certificates and an overlap period is necessary to accept incoming messages encrypted with either the old or the new certificate. Note that the rollover certificate is never used to sign outgoing messages, which may cause signature verification issues when sending to trading partners that are still using the old certificate.
  • Rollover Certificate Password The password required to access the Rollover Private Certificate.

Application URLs

Settings and displayed values related to accessing Arc from the public web.

  • Asynchronous MDN URL The URL at which Arc will listen for asynchronous MDN responses. This value is automatically generated based on the Base URL and the default MDN endpoint, ReceiveMDN.rsb. This endpoint rarely needs to be modified.
  • Receiving URL The URL at which Arc will listen for incoming AS2 messages. This URL should be advertised to all trading partners.
  • Publish my AS2 profile settings at Public.rst If enabled, an endpoint will be exposed where trading partners can view AS2 configuration details including identifiers, URLs, algorithms, and certificates.
  • Public URL The endpoint at which trading partners can view AS2 configuration details. This URL can be advertised to trading partners to simplify the communication of AS2 specifics.
  • Public Certificate The public key certificate to be advertised in the public configuration page. This should be set to the encryption certificate that trading partners should use when sending AS2 messages to Arc. This certificate should have the same name as the Private Certificate but with a ‘.cer’ extension.

Connector Configuration

After configuring the AS2 Profile, AS2 Connectors can be created in the Flows page and configured for a specific trading partner.

Settings Tab

Trading Partner Info

Settings for identifying and connecting to a specific AS2 trading partner.

  • Connector Id The static name of the connector. All connector-specific files are held in a folder by the same name within the Data Directory.
  • Connector Description An optional field to provide free-form description of the connector and its role in the flow.
  • AS2 Identifier The AS2 identifier specific to the target trading partner. This value is included in the AS2 headers for outgoing messages, and it is also used to route incoming AS2 messages to the appropriate AS2 Connector.
  • Partner URL The trading partner’s public endpoint where outgoing AS2 messages should be sent.

Connection Info

Settings related to connection parameters for the specified trading partner.

  • Send Message Security Whether to sign and/or encrypt outgoing AS2 messages. Signatures and encryption are strongly recommended.
  • Receive Message Security Whether to require that signatures and encryption are present for incoming AS2 messages. An error will be thrown if a received message does not have a required security parameter.
  • Compression Whether to compress the payload of outgoing messages.
  • Connection Timeout The length of time the connector will wait for a connection response before throwing a timeout error.

MDN Receipts

Settings related to requesting MDNs when sending AS2 messages.

  • Request MDN Receipt Whether an MDN Receipt should be returned in response to outgoing AS2 messages. Requesting MDN Receipts is strongly recommended.
  • Security Whether the MDN Receipt should include a signature block verifying the message integrity and identity of the recipient. MDN Security is strongly recommended.
  • Delivery Whether the MDN should be returned as a direct response to the outgoing AS2 message (Synchronous) or returned later as part of a separate connection (Asynchronous). Synchronous MDNs are recommended unless the size of AS2 messages is very large (50MB is a common threshold), in which case processing the message and delivering a synchronous MDN may strain the connection timeout duration.

Trading Partner Certificates

Settings related to the public key certificates provided by the trading partner.

  • Encryption Certificate The public key certificate used for AS2 encryption when sending messages. This certificate must be paired with the trading partner’s private certificate, and the trading partner should provide a public key certificate when sharing AS2 configuration details.
  • SSL Server Certificate The public key certificate used to verify the identity of an SSL/TLS server. Only necessary if the partner’s AS2 system requires HTTPS (rather than HTTP). If the trading partner does not provide an SSL server certificate, this setting can be left blank, to allow the underlying OS/JVM to perform certificate validation, or it can be set to ‘Any Certificate’ to unconditionally trust the target server’s identity.

Public Profile

The AS2 profile configuration details published on a public endpoint accessible to trading partners. This endpoint is configured within the Profile page.

Automation Tab

Automation Settings

Settings related to the automatic processing of files by the connector.

  • Send Whether files arriving at the connector will automatically be sent as AS2 messages.
  • Retry Interval The amount of time before a failed send is retried. A retry is triggered when the server does not respond to a send attempt, or responds negatively to communicate that the file was not received.
  • Max Attempts The maximum number of times the connector will process the input file. Success is based on a successful server acknowledgement and validation of the receipt (when requested synchronously). If this is set to 0, the connector will retry the file indefinitely.
  • Resend Interval The amount of time before unacknowledged messages are resent. A resend is triggered when the server receives the file, but an asynchronous MDN Receipt is not provided within the expected timeframe.
  • Max Attempts (async) The maximum number of times the connector will process the input file when asynchronous receipts are requested. Success is based on the return of an asynchronous receipt within the Resend Interval after a successful server acknowledgement (if a successful server acknowledgement is not returned, Max Attempts is applied instead). If this is set to 0, the connector will resend the file indefinitely.

Advanced Tab

Very Large Message Support (VLM)

Settings used to support sending large AS2 messages.

  • Streaming - (HTTP chunked transfer encoding) Whether to use HTTP Chunked Transfer Encoding when sending messages. This allows the application to send portions (chunks) of the message sequentially to avoid overloading the connection. Note that not all AS2 systems support this type of transmission.
  • AS2 Restart Whether to support resuming transmissions that were interrupted. This is useful when streaming large messages in chunks. Note that not all AS2 systems support this feature.

Reliability

Settings related to the Reliability feature of the AS2 protocol.

  • AS2 Reliability Whether to reuse AS2 Message IDs when re-sending a document. This helps prevent the same document from being processed twice on the receiving side.

Alternate Local Profile

Settings that override the AS2 configuration in the Profile page for this specific AS2 Connector. Setting an alternate local profile allows the use of different local certificates and identifiers for certain trading partners.

  • Local AS2 Identifier Your AS2 identifier. Overrides AS2 Identifier in the Profile section.
  • Private Certificate The certificate that will be used to decrypt incoming messages and sign outgoing messages. Overrides Private Certificate in the Profile section.
  • Certificate Password The password required to access the local private certificate.

SSL Client Authentication

Settings related to client authentication when two-way SSL authentication is required.

  • Use private certificate from the Profile tab Whether to use the same Private Certificate configured in the Profile page as the SSL certificate for client authentication.
  • Private Certificate The private certificate presented during SSL client authentication. Only applicable if not using the same private certificate from the Profile page.
  • Certificate Password The password required to access the SSL client certificate.

HTTP Authentication

Settings related to HTTP client authentication.

  • Use HTTP Authentication Whether client HTTP Authentication is enabled.
  • HTTP Authentication Type Whether to provide HTTP authentication credentials in an encrypted format (Digest) or in plain text (Basic). Basic authentication should only be used if the the connection is an HTTPS connection (rather than HTTP).
  • User The User credential for HTTP client authentication.
  • Password The Password credential for HTTP client authentication.

Custom Headers

An arbitrary set of custom headers to be included as part of the outgoing message.

Performance

Settings related to the allocation of resources to the connector.

  • Max Workers The maximum number of worker threads that will be consumed from the threadpool to process files on this connector. If set, overrides the default setting from the Profile tab.
  • Max Files The maximum number of files that will be processed by the connector each time worker threads are assigned to the connector. If set, overrides the default setting from the Profile tab.

Other Settings

Settings not included in the previous categories.

  • Async MDN Timeout The HTTP response timeout to observe when returning an asynchronous MDN receipt, in seconds. By default, this value is set to 60 seconds.
  • Duplicate File Action How the connector should behave when receiving an AS2 message with a filename that the connector has seen before. If set to Warning, the connector will process the file but return a warning in the MDN. If set to Failure, the connector will not accept the file and return an error in the MDN. The connector will “remember” filenames that are received for a duration according to Duplicate File Interval.
  • Duplicate File Interval The length of time, in minutes, that a file with the same filename will be considered a duplicate. In other words, the length of time the connector will “remember” that a specific filename has already been received. If set to 0, the filenames will be stored until the server is restarted.
  • Encryption Algorithm The algorithm to use when encrypting outgoing AS2 messages.
  • Send Filter A glob pattern filter to determine which files in the Send folder will be sent by the connector (e.g. *.txt). Negative patterns may be used to indicate files that should not be processed by the connector (e.g. -*.tmp). Multiple patterns may be separated by commas, with later filters taking priority except when an exact match is found.
  • Extension Map A set of name-value pairs that maps file extensions to the desired HTTP Content-Type header value. By default, the application will map the following file extensions to content types:
    .xml -> application/xml
    .edi or .x12 -> application/edi-x12
    .edifact -> application/edifact.
    All other file extensions are sent with an application/octet-stream content type. To add or overwrite mappings, this setting should be a comma-delimited list in extension=contenttype syntax (e.g. .txt=text/plain,.edi=application/edifact).
  • HTTP Subject The HTTP Subject header to be included in the outgoing AS2 message. This header is not used in the AS2 protocol, but may be used by some solutions for additional business logic processing. Log Level The verbosity of logs generated by the connector. When requesting support, it is recommended to set this value to Debug.
  • Log Requests Whether the payload and request logs should be written when sending messages. This increases the disk space consumed when sending large messages. When requesting support, it is recommended to include requests in the debug logs and provide these along with the support request.
  • Message Id Used to overwrite the AS2 Message Id automatically generated by the connector.
  • Temp Receive Directory If set, the application will write received files to the temporary directory as they are received, then move the finished file to the Receive directory. This ensures that partial files are never present in the Receive directory, even when receiving very large files.
  • Parent Connector The connector from which settings should be inherited, unless explicitly overwritten within the existing connector configuration. Must be set to a connector of the same type as the current connector.
  • Parse FDA Extensions Whether to parse outgoing filenames to include FDA-specific headers in the AS2 message. If enabled, files in the Send directory should have the FDA center and the FDA submission type as the first two parts of the filename, separated by periods (e.g. CDRH.eMDR.myfile.txt). The application will automatically translate these filename prefixes into the appropriate FDA-required headers.
  • Signature Algorithm The algorithm to use when signing outgoing messages. The same algorithm will be requested for the corresponding MDN receipts.
  • Partner Signing Certificate If the trading partner uses separate private certificates to sign messages and to decrypt messages, this should be set to the public key certificate that corresponds to the partner’s signing certificate. The trading partners should be able to provide this public key certificate.
  • Log Subfolder Scheme Instructs the connector to group files in the Logs folder according to the selected interval. For example, the Weekly option instructs the connector to create a new subfolder each week and store all logs for the week in that folder. The blank setting tells the connector to save all logs directly in the Logs folder. For connectors that process many transactions, using subfolders can help keep logs organized and improve performance.
  • Log Messages Whether the log entry for a processed file will include a copy of the file itself.
  • Save to Sent Folder Whether files processed by the connector should be copied to the Sent folder for the connector.
  • SSL Enabled Protocols The list of SSL/TLS protocols supported when establishing outgoing connections. It is strongly recommended to only use TLS protocols. Some obsolete operating systems do not support TLS 1.2.

Miscellaneous

Settings for specific use cases.

  • Other Settings Allows configuration of hidden connector settings in a semicolon-separated list, like setting1=value1;setting2=value2. Normal connector use cases and functionality should not require use of these settings.

Establishing a Connection

Trading partners must share some of the connection details that are required when configuring a new AS2 Connector. At a minimum, these details should include:

  • AS2 Identifier
  • Partner URL
  • Partner Certificates

AS2 Identifier

Your trading partner identifies themselves in an AS2 transaction via their AS2 Identifier. When sending outgoing requests, the AS2 Identifier is used in the header of the request to indicate the recipient.

To establish an AS2 self-test, the identifier should be set to the same value as the AS2 Identifier in the Profile section.

Note: This value is case-sensitive.

Partner URL

The Partner URL is the endpoint where the trading partner receives AS2 transmissions. Outgoing AS2 messages are sent to this target endpoint, which much be unique for each trading partner. The Partner URL can be tested with a web browser to check for any networking or connectivity issues.

To establish an AS2 self-test, the target URL should be either identical or nearly identical to the Receiving URL in the Profile page. The domain name from the Profile page can be replaced with the loopback address ‘localhost’ to keep the AS2 transaction within the local network. An example local self-test URL is http://localhost:8001/pub/Receive.rsb.

If the domain name is not replaced with ‘localhost’, then the AS2 message is routed outside of the local network. This can be used to check network configuration settings and to make sure that the message can reach Arc through any firewalls.

Trading partners may sometimes provide more than one URL: a Receiving URL and a URL for asynchronous MDNs. In this case, only the Receiving URL (Partner URL) needs to be configured; the application can read the Asynchronous MDN URL from incoming AS2 transmissions.

Partner Certificates

Each AS2 Connector must be configured with the public key certificate(s) for the target trading partner. The trading partner provides the certificates necessary to encrypt and verify AS2 messages exchanged with them. Arc accepts X.509 public key certificates (files with .cer, .der, or .pem extensions).

Typically the trading partner will provide a single certificate, which should be configured in the Encryption Certificate field.

If the trading partner provides multiple certificates, they should clarify the purpose of each certificate. If the partner provides a full certificate chain (as acquired from a commercial certificate authority), only the leaf certificate needs to be configured (the last certificate in the chain). Rarely, a separate public key certificate may be required to verify the partner’s digital signatures. In this case, set the signature verification certificate under Advanced -> Other Settings -> Partner Signing Certificate.

To establish an AS2 self-test, the ‘test.cer’ public key certificate included with the application should be set as the Encryption Certificate and the ‘test.pfx’ private certificate should be set as the Private Certificate in the Profile page.

Send and Receive Files

After the AS2 profile and partner-specific AS2 Connectors have been configured, files can be securely sent and received.

Send Files

Within an AS2 Connector, the Input tab displays the files that should be sent to the target trading partner. If Send Automation is enabled, files that reach the Input/Send Folder of the connector will automatically be packaged and sent. Successful transmissions are indicated by a green ‘Sent’ status, while warning and error statuses are represented in yellow and red. The log files for failing or successful transmissions can be accessed by expanding the row associated with the transmitted file.

The Create Test Files button can be used to generate a simple series of test files to send to the trading partner.

Resend and Retry

An AS2 Resend is triggered when the trading partner is expected to return an asynchronous MDN, but fails to do so within the Resend Interval duration (by default this is 60 minutes). The application then attempts to resend the transmission. The application will continue re-sending the message until an MDN is received or the Max Attempts (async) is exhausted.

A Retry is triggered when the HTTP response from the trading partner indicates that the server has not received the transmission (i.e. the response is not a positive 200 OK status). This often indicates a networking or connectivity issue, which are often transient. The application will retry the transmission every Retry Interval minutes until the transmission is received or the Max Attempts is exhausted.

Receive Files

Within an AS2 Connector, the Output tab displays the files that have been received by the application and routed to the connector (based on the AS2 identifiers present in the incoming AS2 message). Each file row can be expanded to display a list of available logs for the transmission.

These files are available in the Output/Receive Folder of the connector. If the connector is connected to other connectors in the flow, files will automatically be moved from the Output/Receive Folder of the AS2 Connector to the Send directory of the next connector in the flow.

The AS2 protocol does not allow for actively pulling files from trading partners; the AS2 Connector can only passively wait for a trading partner to send a file.

Troubleshooting Receiving Files

Issues that occur when receiving AS2 messages may be harder to track down than issues that occur when sending files. When an error occurs while sending a file, the error is immediately reported in the Input tab (and Transaction Log) for the AS2 Connector. When receiving files, errors and other debug information may appear in multiple places.

After Arc receives an AS2 message, it attempts to route that message to a specific AS2 Connector, based on the AS2 Identifier configured in the connector (and the AS2 Identifiers present in the incoming message). There are three possible locations to check for logging information, depending on whether this routing operation succeeds:

  • The Output tab for the AS2 Connector (configured for this trading partner) will have error logs if Arc could successfully route the message.
  • The Application Log will have error logs if Arc could not successfully route the message.
  • If no logs appear in the AS2 Connector nor the Application Log, then the AS2 message never reached Arc in the first place.

In the last case, where no logs appear in the AS2 Connector nor the Application Log, the issue is likely related to network configuration. Often this occurs as a result of firewall interference, so it is important to confirm that the trading partner and the system hosting Arc has opened the appropriate ports on the firewall and whitelisted IP Addresses if necessary. There may also be a simple misconfiguration on the trading partner’s side, such as sending to the incorrect endpoint (the partner should send to the Receiving URL value found in the AS2 Profile tab of the Profile page).

What Happens in an AS2 Exchange

For all of its complexity in terms of its applications, AS2 boils down to two basic parts: A document is sent from an AS2 sender to an AS2 receiver via HTTP, a very flexible client-server protocol that serves as the backbone of the World Wide Web. The receiver acknowledges the transfer by providing the sender with a receipt.

The following illustration demonstrates the different steps that are taken in further detail.

AS2 Diagram

Step 1: EDI Document Preparation

In an AS2 exchange, any type of document can be sent, from a text file to a PDF. Typically, however, most trading partners implement a standard for specific document types.

The most common document types are electronic data exchange (EDI) X12 documents (.x12 or .edi files), , Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) documents (.edifact files), or XML files (.xml files) The preparation of the document takes place before the AS2 communication begins.

EDI (Electronic Data Interchange) is a general term for the transfer of documents between trading partners and the standards that are adhered to. It is also represented as EDI over the Internet (EDIINT)

Step 2: AS2 Packaging

The AS2 document is prepared for sending. This consists of three types of document transformation. If the document consists of data that is compressible (that is, not binary data), the document may be compressed using the zlib compression algorithm to reduce the size of the transported data. The data is typically signed using the private key of the sender to ensure the sender’s identity as the creator of the document (usually with the SHA-1 signing algorithm). Finally, the data may be encrypted using the receiver’s public key so only the trading partner can read the data (usually using the 3DES encryption algorithm). This step may be skipped if the data is going to be delivered by a secure transport mechanism, such as HTTPS.

S/MIME is the set of standards used for encryption and signing of a message/document. It not only governs the functions of signing and encryption, but it also provides standards for the formatting of the final message so that a compliant reader can easily identify the structure of the message.

Step 3: HTTP/S Delivery

The prepared document is then delivered to the trading partner over the Internet to the trading partner’s Web server over the HTTP or HTTPS protocol.

Step 4: AS2 Unpackaging

The receiver of the prepared document then un-packages to retrieve the EDI document. If the data was encrypted, the prepared document is then decrypted using the receiver’s private key. If the data was signed, the signature on the document is verified using the sender’s public key to ensure the identity of the sender. If the document has been compressed, the prepared document is then decompressed to produce the original EDI document.

Step 5: EDI Processing

At this point, the AS2 receiver passes the un-packaged EDI document to any back-end process that handles the data to perform any additional business logic. Now, the EDI document is parsed and the receiver may even initiate a new AS2 transaction where the roles of sender and receiver are reversed. In particular with EDI-X12 documents, a 997 Functional Acknowledgment is often sent to the original sender to signify that the original EDI document was processed in the back-end business logic.

Step 6: MDN Reply

The receiver sends back an message delivery notification (MDN) to the sender, in most cases signed with the receiver’s private key. The MDN is a receipt that is returned in an AS2 exchange and used to report to the sender what was received and whether or not it was received successfully.

The MDN contains information about whether or not the document was successfully un-packaged, as well as a message digest that is calculated over the received payload. The MDN is then returned to the sender in one of two ways, depending on how the sender asked for the MDN to be delivered. In a synchronous transaction, the receiver returns the MDN in the HTTP reply from the receiver’s Web server. In an asynchronous transaction, the HTTP reply contains a simple acknowledgment (200 OK), and the MDN is returned over a separate connection (this is usually the case if the un-packaging of the AS2 transmission is expected to take a while).

Step 7: MDN processing

When the sender receives the MDN from the receiver, the MDN signature is verified if the MDN was signed. The status of the MDN is checked to see if the receiver was successful in processing the transaction, or if they encountered an error that was reported in the MDN. Finally, the message digest reported in the MDN is matched against a message digest that was calculated over the EDI data that was sent. With a signed MDN, the sender can verify that the receiver of the message received the entire contents of the EDI document as it was intended to be delivered.

Certificates

The AS2 Connector makes use of both private key certificates and public key certificates.

Private Key Certificates

The AS2 Connector allows you to specify certificates in PKCS#12 format (a .pfx file or a .p12 file). Private key certificates are used to perform the two operations that only the holder of the private key should be able to perform:

  • Signing data to provide proof of your identity.
  • Decrypting data that was intended for you.

Public Key Certificates

Public key certificates are given to you by your trading partner. The AS2 Connector allows you to specify public key certificates in X.509 format (a .cer or .der file). Public key certificates are used to work in reverse of the operations that require a private key. These operations include:

  • Verifying signatures created by your trading partner.
  • Encrypting data so that only your trading partner can read it.

Common Errors

Below is a list of common errors, their causes, and the recommended solution. Please contact [email protected] for more information.

ERROR:

“The receipt signature could not be verified: Message digest mismatch in signature”

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.

Sometimes this error can be caused by Anti-Virus or File Security software improperly stripping part of the MDN response. There is a known issue with ESET’s Application Protocol Filtering feature where folded MDN headers may be invalidated due to whitespace removal.

Resolution

First, take a look at the MDN returned by the partner for apparent issues. Download the .mdn file for the transaction where this error is thrown and either send it to [email protected] along with a description of the issue, or investigate independently.

It may also be helpful to reach out to the trading partner to confirm what AS2 solution they use. Arc is interoperable with any Drummond-certified AS2 solution.

ERROR:

“The receipt signature could not be verified: The certificate specified does not match the signature”

Cause

MDN receipt are signed with a private key, and this signature is validated with the corresponding public key. This error suggests that the public key configured to verify signatures from this partner is incorrect.

Resolution

Often, the same public key certificate that is used for encryption is also used to verify signatures. In this case, check the certificate set under Settings -> Encryption Certificate in the AS2 Connector to make sure it is correctly configured for this trading partner.

Sometimes, trading partners will use a separate certificate for signatures. In this case, set the Advanced -> Partner Signing Certificate setting to the public key certificate that matches the partner’s signing key.

ERROR:

“The receipt signature could not be verified: Message digest was encrypted with unknown algorithm”

Cause

This is 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, including the final published build of v2016, support SMIME 3.2. Older versions will require and upgrade to resolve this error.

ERROR:

“MDN Error: Authentication failed”

OR

ERROR:

“MDN Error: Signature Authentication failed: Could not authenticate signer’s identity”

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

Check that the private certificate configured in the Arc AS2 profile is correct, and that the trading partner has configured the matching public key certificate on their end.

ERROR:

“MDN Error: Unexpected processing error”

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, the trading partner should be contacted for further information about what caused the failure.

ERROR:

“System error: Connection refused”

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.

Resolution

Check that the target URL 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.

ERROR:

“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”

OR

ERROR:

“Connection timed out”

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 (typically 60 seconds). This is often the result of firewall interference with the server’s response, but it may also indicate incorrect connection parameters.

Resolution

Check that firewalls are not preventing the server’s response from being returned. If the server is also behind a firewall, check that the IP from which the AS2 messages are being sent is whitelisted in the server’s firewall.

If firewalls have been ruled out, check that the target URL is correct.

ERROR:

“Synchronous MDN expected but not received”

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 provide it to [email protected] along with a description of the issue.

ERROR:

“Unsigned MDN received, but signed MDN requested”

Cause

This error is thrown when the response from the trading partner is expected to be a signed MDN receipt, but is instead some other content. This could be an unsigned MDN receipt, or a response that is not an MDN at all.

Resolution

Check the contents of the .MDN log file from the failed transaction. This file will contain the server reply, whether it is an unsigned MDN or some non-MDN response. The contents of the .MDN log file will indicate the next steps; if the server response is not an MDN at all, it may contain an error or indicate that the endpoint where the AS2 request was sent is not an AS2 receiving endpoint at all. If the .MDN log file contains an unsigned MDN, this indicates a configuration issue in the trading partner’s system.

ERROR:

“Unable to find valid certification path to requested target”

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.

ERROR:

“Key does not exist”

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. Navigate to the ‘data’ folder within the Arc installation directory, find the folder for the relevant AS2 Connector, and open the ‘port.cfg’ file in a text editor. Make sure the following line is present in order to enable the managed security implementation while loading certificates:

CertUseManagedSecurityAPI = true

ERROR:

“Input string was not in a correct format”

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 that invalid string processing is not being performed. It may be easiest to provide the scripts directly to [email protected] to confirm whether the scripts are causing the issue.

ERROR:

“500 Internal Server Error”

Cause

This HTTP error indicates a general server-side failure. The AS2 message was successfully received, but some error occurred when processing the message and no further debugging information is available.

Resolution

The only client side setting that could be related to this issue is the target URL. If this is correct, then server-side logs must be consulted to learn more about what caused the processing failure. Consult with the trading partner to see if these server logs are available.

ERROR:

“404 Not Found”

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.

ERROR:

“401 Unauthorized”

Cause

This HTTP error indicates that authorization is required to reach the specified URL. This may be SSL Client Authentication or HTTP Authentication.

Resolution

If SSL Client Authentication is required, set the appropriate SSL certificate in the Advanced -> SSL Client Authentication section of the connector configuration. If HTTP Authentication is required, set the appropriate credentials in the Advanced -> HTTP Authentication section of the connector configuration.

To see if HTTP Authentication is required, test a connection to the target URL with a web browser and notice any prompts for user/password credentials.

ERROR:

“Incoming request did not match a configured trading partner profile”

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.

ERROR:

“Error during handshake: The token supplied to the function is invalid”

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.

ERROR:

“Error during handshake: the buffer supplied to a function was too small”

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

Arc comes with an internal implementation of crypto operations, and this managed implementation can be enabled to workaround the Windows CryptoAPI limitation. Navigate to the ‘data’ folder within the Arc installation directory ‘profile.cfg’ file in a text editor. Make sure the following line is present under the [Application] section of this file:

UseManagedSecurityAPI = true

As an alternative to using the managed security provider, use a third-party system crypto tool to disable the two affected ciphers at the OS level.

ERROR:

“Error during handshake: the function requested is not supported”

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

TLS versions can be enabled within the AS2 Connector under Advanced -> Other Settings -> SSL Enabled Protocols. Confirm with the trading partner which SSL/TLS versions are supported and configure the connector appropriately.