Configuring AS2

A site administrator configures AS2 on your site.

AS2 requires that you and your trading partner agree on identifiers for your communication. These are sometimes referred to as "AS2 Identity", "AS2 name", "AS2 code", "AS2 station", or "AS2 To and AS2 From" identifiers.

You need your own x509 Certificate and Key for decryption and digital signing. We can generate this for you, or you can provide your own. Self-signed certificates work. These certificates decrypt data received from your trading partner and digitally sign data sent to your trading partner.

You provide only the public x509 Certificate to your trading partner. Keep your private key and any package containing it private.

You need your trading partner's public x509 Certificate for encryption. Contact your trading partner and ask them to provide the public AS2 certificate for this connection. This certificate encrypts data you send to your trading partner and validates the digital signature of data received from your trading partner.

You need the AS2 URL of your trading partner, sometimes referred to as the "endpoint URL". Contact your trading partner and ask them to provide the AS2 URL for this connection. This URL is used to connect to your trading partner's AS2 system and deliver data.

Configuring Your AS2 Identity

You can create as many AS2 identities as your business requires. Most organizations have a single AS2 Identity, but some require multiple identities to represent, and route data to, subsidiaries or business units.

On the Add an AS2 Identity page, enter your desired AS2 Identity and choose a Certificate Source:

• Generate in browser generates a self-signed certificate and key. This is the default for a new identity.
• Import PKCS#12 File (PFX or P12) imports a certificate and key together from a .pfx or .p12 file. Select the file in PKCS#12 File and enter its password in PKCS#12 Password. Leave the password blank if the file has none.
• Upload or Paste Certificate and Private Key Separately accepts the certificate and key as separate PEM or CRT inputs.

Whether supplied separately or in a PKCS#12 package, your certificate and private key must be a matching pair. Files.com uses the private key to decrypt messages encrypted for your certificate and to sign outgoing messages that your trading partner verifies with that certificate. A key from another pair cannot perform those operations. A package containing only a public certificate cannot be used for your identity.

The API also supports importing password-protected separate private keys with their password. An unencrypted private key does not require a password.

A PEM or CRT public Certificate begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----.

Private key headers include -----BEGIN PRIVATE KEY-----, -----BEGIN RSA PRIVATE KEY-----, and -----BEGIN ENCRYPTED PRIVATE KEY-----, each with its corresponding END line. Include the complete key, including those lines. The ENCRYPTED PRIVATE KEY form requires a password; RSA private keys can also be password protected.

You can use fully valid and chained Certificates and Keys, or use self-signed Certificates and Keys.

Configuring Trading Partners

Enter the trading partner's AS2 URL, as provided to you by your trading partner. The URL can include the Fully Qualified Domain Name (FQDN), or IP address, of the trading partner, the port number (if a non-standard port is being used), and subdirectory path.

Enter the trading partner's AS2 Identity, as agreed upon between you and your trading partner.

On the Add an AS2 Partner page, choose a Certificate Source. Upload or Paste Public Certificate accepts the partner's public encryption certificate in PEM or CRT format. To import a .pfx or .p12 file, choose Import PKCS#12 File (PFX or P12), select it in PKCS#12 File, and enter its password in PKCS#12 Password. Leave the password blank if the file has none.

Files.com needs only the partner's public certificate. A PKCS#12 file without a private key must contain exactly one certificate. If the file includes a private key, Files.com imports its matching public certificate and discards the key. Ask your partner to share only their public certificate, keeping their private key private.

A PEM or CRT public Certificate begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----.

You can use fully valid and chained public encryption Certificates, or self-signed public encryption Certificates. Your trading partner supplies you with this certificate.

Select which of your AS2 Identities you want to use with this trading partner.

Choose the Server certificate option that corresponds to the security level of the trading partner's AS2 URL.

If your trading partner's AS2 URL is protected by a valid and chained SSL Certificate, choose the "Require valid, chained, trusted, matching TLS/SSL certificate (Recommended)" option.

If your trading partner's AS2 URL uses a self-signed, unchained, expired, or non-matching SSL Certificate, choose the "Allow self-signed, unchained, expired, or non-matching TLS/SSL certificate" option.

If your trading partner's AS2 URL uses Basic Authentication, requiring an AS2 username and password, use the Enable Basic Authentication option. Provide the AS2 username and password to use when sending messages to this trading partner.

Files.com sends outgoing AS2 messages signed and encrypted. For incoming messages, your partner can send signed or unsigned messages, with or without S/MIME message encryption, subject to the signature validation level below. Agree on those choices with your partner independently: a requirement for a valid signature does not require message encryption, and message encryption does not satisfy a signature requirement. HTTPS transport encryption protects the connection even when the incoming message has no S/MIME encryption.

Choose an MDN validation level for receipts this trading partner returns for your outgoing messages. This option determines how much validation is performed on the returned MDN to consider the AS2 transmission a success.

At Normal and Strict, a signature made with a different key fails validation. Verifying against the configured partner certificate ties the signed receipt to the key you exchanged with that partner. If your partner changes their signing key, update their configured certificate at the agreed time.

Auto helps establish a compatible validation requirement when setting up a trading partner. It selects Normal only when the receipt passes Normal's checks, including signature verification against the configured partner certificate. If the MIC and Disposition are valid but the signature is absent or does not verify against that certificate, Auto selects Weak. Choose Normal or Strict explicitly when your business process requires a signed receipt verified with the partner's configured certificate.

Saving the selected level gives later transmissions a consistent requirement: a subsequent receipt that fails that level fails validation instead of causing Auto to select a weaker level for it.

Choose a signature validation level for incoming AS2 messages from this trading partner. This setting is separate from MDN validation, which applies to receipts returned for your outgoing transmissions. Use Normal when incoming messages must have a valid signature.

Normal verifies that the message was signed with the private key corresponding to the configured partner certificate and that the signed content is unchanged. It rejects unsigned messages, signatures made with a different key, and content that does not match the signature. Self-signed certificates, certificates without an S/MIME signing purpose, and certificates that are expired or not yet valid can all validate signatures at this level. The same rules apply when Auto selects Normal.

This keeps incoming business exchanges running while you coordinate certificate renewal with your partner. The expiration date shown in the AS2 Trading Partners table helps you plan that renewal; it does not stop acceptance of incoming signatures at Normal. Update the configured certificate or delete the trading partner when you need to change the accepted signing key or end the partnership.

Files.com returns a signed MDN with a Message Integrity Check (MIC) for successfully processed incoming messages, including unsigned messages. The receipt acknowledges the received content; its signature and MIC do not establish that the incoming message was signed or that its signature was validated.

You can configure additional HTTP headers for AS2 transmissions to the trading partner. This is useful when your trading partner applies additional HTTP protection to their AS2 service that requires custom headers to approve the transmission. Only use this setting if your trading partner requires it.

You can specify the MIME type of the AS2 transmissions to the trading partner. By default, Files.com attempts to automatically infer the MIME type and uses that for the transmission. If the MIME type cannot be inferred, a type of application/octet-stream is used. Configure this setting if your trading partner requires you to define a specific MIME type for your transmissions to them.

The Dedicated IPs setting applies separately to each trading partner and is available when your site has dedicated IP addresses. Enabling it sends outbound AS2 messages to that partner from the site's default dedicated addresses, rather than an additional Custom Domain's addresses. With the setting disabled, messages use the Files.com general IP pool. We recommend enabling it when your trading partner's firewall only allows connections from specified IP addresses, and giving the partner your site's default dedicated addresses to allowlist.