AS2 security
This page explains the Security and Connection settings of a partner’s AS2 profile. They decide how messages are signed and encrypted, which signatures you accept, and how the HTTPS connection to the partner is checked.
What signing and encryption are for
Signing proves that a message comes from the partner and that nobody changed it. The sender signs with its private key. The receiver checks the signature with the sender’s public certificate.
Encryption keeps the message secret on the way. The sender encrypts with the receiver’s public certificate. Only the receiver’s private key can decrypt it.
HTTPS also protects the connection. But signing and encryption protect the message itself, also where a proxy ends the HTTPS connection. A signature also stays with the message as proof of who sent it. Most partners expect both.
Recommended: keep the defaults. Sign with sha256, encrypt with AES-256-CBC, and require both from the partner.
Lower them only when a partner cannot work with them.
Security settings
| Setting | What it does | Default |
|---|---|---|
| Partner Certificate | The partner’s public certificate. MicroB2B encrypts to it and checks the partner’s signatures with it. | none |
| Encryption Algorithm | How messages to the partner are encrypted. None sends them unencrypted. | AES-256-CBC |
| Our Certificate | Optional. Replaces the organization’s certificate for this partner. It signs messages and receipts to this partner and decrypts what the partner sends. | the organization’s |
| Signature Algorithm | How messages to the partner are signed. None sends them unsigned. | sha256 |
| Require Incoming Signatures | Refuse unsigned messages from the partner. | on |
| Require Encryption | Refuse unencrypted messages from the partner. | on |
| Additional Partner Certificates | More certificates whose signatures you accept. Never used to encrypt. | none |
Encryption algorithms: 3DES-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-GCM, AES-256-GCM, or None.
Choose AES-256-CBC unless your partner asks for something else.
3DES-CBC is only for old partners that support nothing better.
Signature algorithms: sha1, sha256, sha384, sha512, or None.
Choose sha256 unless your partner asks for something else.
Encryption needs a Partner Certificate
An encryption algorithm without a Partner Certificate is refused when you save.
A Partner Certificate with the algorithm at None is allowed. Your messages then go out unencrypted, and MicroB2B still checks the partner’s signatures with the certificate.
Checking the partner’s signatures
A signed message is always checked. There is no setting to skip that. A signature is never accepted unless MicroB2B can check it against a certificate.
MicroB2B checks signatures against these certificates:
| Signed by the partner | Checked against |
|---|---|
| Message | The Partner Certificate and the Additional Partner Certificates. With neither, a signed message is refused. |
| Receipt (MDN) | 1. The Partner MDN Signature Certificates, if set. 2. Otherwise the Partner Certificate and Additional Partner Certificates. 3. With none of these, the certificate in the receipt, which must chain to the system’s trusted authorities. |
MicroB2B uses only the first source that is set. If that source does not match, the signature is refused. It does not try the next one.
A partner with one key pair needs only the Partner Certificate. Use Additional Partner Certificates when the partner changes certificates, or signs with more than one.
Messages MicroB2B refuses
| Problem | Receipt the partner gets |
|---|---|
| Unsigned or unencrypted, while the profile requires it | insufficient-message-security |
| The signature does not verify | authentication-failed |
| Encrypted with an unsupported algorithm, such as DES or RC2 | decryption-failed |
| Signed with an unsupported digest, such as MD5 | authentication-failed |
MicroB2B keeps the refused message as it arrived.
Its status is Error with the reason, and it is not passed on.
Details partners sometimes ask about
MD5 is not supported for signing or for receipts. When a partner asks for an MD5 signed receipt, MicroB2B uses the first other algorithm the partner lists. If the partner lists none, it uses SHA-1.
Algorithm names. Partners write digest names as sha256 or sha-256, in any case. MicroB2B accepts both.
Its own messages use the sha256 form.
Signature formats. MicroB2B accepts both ways partners sign a message: with the signature beside the content (multipart/signed, the usual one), or with the content inside the signature.
MicroB2B itself always signs with multipart/signed.
Compression order. Incoming messages may be compressed before or after signing. MicroB2B reads both.
Transfer encoding. Older partners sometimes send the file in base64 or quoted-printable.
MicroB2B decodes it and stores the bytes the partner meant to send.
An unknown encoding, or content that is not valid in its encoding, is refused with unexpected-processing-error.
The partner’s TLS certificate
These settings are in the Connection section. They control how MicroB2B checks the partner’s HTTPS endpoint. They apply to your messages and to asynchronous receipts you send to the partner.
MicroB2B requires TLS 1.2 or newer. By default it trusts the same authorities as the operating system, and checks that the certificate names the endpoint’s host.
Partner’s TLS Server Certificates. Add a certificate here when the partner uses a private CA or a self-signed server certificate. MicroB2B then trusts it for this partner only, on top of the system’s trusted authorities. The chain must still verify, and the host name must still match.
Our TLS Client Certificate. Some partners require a client certificate (mutual TLS). Choose one of your certificates with a private key. There is no organization-wide default.
Accept the pinned certificate whatever host it names. Some partners use a self-signed certificate that names no usable host, for example only “mendelson test key 3”. MicroB2B refuses such a certificate even when it is listed. Turn this option on to accept it anyway.
With the option on:
- The certificate the endpoint presents must be exactly one of the Partner’s TLS Server Certificates, and valid today. The host name is then not checked.
- Every other certificate is checked as usual. A certificate issued by a listed CA, or a publicly trusted one, must still name the host.
- With an endpoint given as an IP address, a certificate that is not listed is refused.
- You need at least one listed certificate. The form and the REST API refuse the option without one.
- The partner’s page shows “TLS Host Name: Not checked for the pinned certificates”.
What you give up: the listed certificate is accepted at any address the endpoint points to. Whoever holds its private key can act as this partner. Use the option only for a certificate you received directly from the partner.
To see which certificate a partner’s server presents, use Check connection. See Testing a partner.
Replay protection
A signed message is accepted only once. Someone who captures a signed message and sends it again is refused. See Messages sent twice. This only works for signed messages, which is one more reason to keep Require Incoming Signatures on.