How to Set Up a Bidirectional AS2 Test (Receiver-Side Verification)

What you get from the dashboard

When you start a bidirectional test (currently in beta on Pro plans and above), the dashboard shows a copy-ready setup block with two values. Copy them exactly:

• Receiver AS2 ID: AS2CERTIFY-VERIFY- followed by a unique token for your test, for example AS2CERTIFY-VERIFY-7KQ2M9XZ. The token is how your inbound message is matched back to your test, so use it verbatim.
• Receiver endpoint URL: https://verify.as2certify.org/as2/receive

Set your own AS2 ID to your real company AS2 identifier, the one you use with production trading partners. The receiver needs your public certificate to validate your signature; import the AS2 Certify verify certificate (public cert only, never a private key) into your keystore for encryption. We never ask for or accept your private key.

Your outbound leg runs first and is graded immediately. The test then waits for your inbound message for up to 60 minutes, and the inbound leg is graded with the same 8-step framework you know from standard tests.

OpenAS2

Define a partner entry for the verify receiver and a partnership from your company to it, following the standard partnerships.xml shapes. Replace the example token with the one from your dashboard:

<partner name="AS2CertifyVerify"
         as2_id="AS2CERTIFY-VERIFY-7KQ2M9XZ"
         x509_alias="as2certify-verify"
         email="ops@example.com"/>

• as2_id: the per-test receiver AS2 ID from your dashboard.
• x509_alias: the keystore alias under which you imported the AS2 Certify verify public certificate.

<partnership name="MyCompany-to-AS2CertifyVerify">
    <sender name="MyCompany"/>
    <receiver name="AS2CertifyVerify"/>
    <attribute name="protocol" value="as2"/>
    <attribute name="content_transfer_encoding" value="binary"/>
    <attribute name="compression_type" value="ZLIB"/>
    <attribute name="subject" value="AS2 Certify bidirectional test: $attributes.filename$"/>
    <attribute name="as2_url" value="https://verify.as2certify.org/as2/receive"/>
    <attribute name="as2_mdn_to" value="ops@example.com"/>
    <attribute name="as2_mdn_options" value="signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, $attribute.sign$"/>
    <attribute name="encrypt" value="aes256"/>
    <attribute name="sign" value="SHA-256"/>
</partnership>

The sendermust reference your existing partner entry (your own AS2 ID and certificate alias). With the partnership saved, drop a test file into the partnership's outbox directory or use your usual send mechanism, exactly as you would for a production trading partner.

RSSBus

In your RSSBus AS2 connector's send settings, configure the outbound operation for the test:

• Destination (To) AS2 ID: the per-test receiver AS2 ID from your dashboard, for example AS2CERTIFY-VERIFY-7KQ2M9XZ.
• Source (From) AS2 ID: your company's AS2 ID.
• AS2 URL: https://verify.as2certify.org/as2/receive.
• Encryption: AES-256, encrypting to the AS2 Certify verify public certificate.
• Signing: SHA-256, signing with your own certificate.
• MDN: request a synchronous signed MDN so the receipt comes back on the same connection.

Cleo Harmony

In Cleo Harmony, model the test as a send-only trading relationship:

• Use your existing AS2 station as your identity: it carries your own AS2 ID and your signing certificate.
• Create a host for the AS2 Certify verify receiver, with the host AS2 ID set to the per-test value from your dashboard and the endpoint URL set to https://verify.as2certify.org/as2/receive.
• Attach the AS2 Certify verify public certificate to that host for encryption (AES-256), and configure signing with your station certificate (SHA-256).
• Create a mailbox for the test partnership, send-only, and trigger a test delivery to it. Confirm the signed MDN comes back before relying on the setup.

What we check on your inbound message

The inbound leg is graded with the same 8-step framework as every AS2 Certify test, with the checks applied to receiving rather than sending. In report order:

1. Listening Endpoint Active: The receiver endpoint answers on the verify host.
2. Message Received: Your inbound test message arrived and was accepted.
3. Sender Certificate Validation: The certificate your system sent with was validated.
4. Decryption Verification: The message, encrypted to the receiver certificate, decrypted correctly.
5. Signature Verification: Your message signature verified against your sending certificate.
6. Payload Integrity Check: The integrity digest matched and the payload was unaltered in transit.
7. MDN Generation: A signed disposition receipt was produced for your message.
8. Response Latency: How quickly the receiver processed and responded to your message.