Certificate Management | Aayu Technologies
EDI and AS2 Gateways by Aayu Technologies
mft gateway logo as2 gateway logo edi generator logo
Link Search Menu Expand Document
logo
Contact

Certificate Management

AS2 Gateway Certificate Store allows you to review, generate, renew and manage your key pairs and trusted certificates in one place.

1 Certificate Types

AS2 Gateway has five main certificate types:

  • STATION: key pairs (private and public keys) assignable to trading stations
  • PARTNER: certificates (signed public keys) assignable to trading partners for encryption or signature verification
  • PARTNER_CHAIN: chain certificates, usually belonging to certificate authorities (CAs), as supplementary information for building the certification-path trust anchors for PARTNER certificates
  • HTTPS: (SSL/TLS) certificates assigned to trading partners’ secure (https://) URLs, for establishing trust when connecting to send outbound messages/MDNs
  • HTTPS_CHAIN: supplementary CA certificates to provide trust anchors for HTTPS certificates

Last two types are rarely used; only if your partner has an HTTPS endpoint with a certificate issued by someone other than the common, globally trusted CAs.

2 Certificate List

The list view offers common details and operations for all certificate types:

  • Common Name (CN) field of the certificate identifier (distinguished name, DN)
  • Alias assigned to the certificate, internally on AS2 Gateway
  • Expires On; expiration date of the certificate
  • Type; certificate type (as listed earlier)
  • Belongs To; the set of entities (partners, stations) that are currently using the certificate, along with the purpose; e.g. as a station’s private key (Priv.Key)
  • Options to export the certificate as:
    • a PEM formatted file (ASCII, safe for copy-paste; supported by most systems)
    • a ,DER formatted file (binary; some systems would request this format explicitly)

Note: CER and CRT files are also of DER format; if your partner has requested for a file with one of these extensions, often it would be enough to rename (change extension) of the downloaded .der file, as .cer or .crt.

For STATION certificates (which are actually key pairs), there are additional export options:

  • To obtain the full key pair (certificate and private key), export the key store using the JKS (Java Keystore) or P12 (PKCS#12) formats.
  • To renew the certificate through an external CA, use the CSR (certificate signing request) generation option. You can share the downloaded .csr file with your CA in order to get the new certificate issued, and then assign it back to the existing STATION entry.

Note: .p12 is more standardized and widely supported. Check out this reference for more details on the differences between .jks and .p12.

3 Certificate Management Operations

3.1 Adding a Trusted Chain Certificate

For many operations like signature verifications, the receiver should be able to build a trust anchor for the sender’s certificate. As explained before, this usually requires that the CA that issued the partner’s certificate, should be trusted at the other end.

If you see errors like “trust anchor for certification path not found”, it indicates that your partner’s CA is missing in your certificate store. In such cases you can simply add the corresponding CA certificate to your store via the Import option. Once uploaded, the certificate will be saved with type PARTNER_CHAIN, automatically including it in the trusted certificates’ collection.

Note:

  • Only certificate files/chains of PEM (.pem) or DER (.der, .cer, .crt) format are expected; do not try to upload complete key stores (.jks, .p12 etc.) or any other file formats.
    • If you are still in the testing/configuration phase, and you uploaded the certificate to fix a failure on an incoming message, you can replay the message to confirm that it gets processed correctly - without waiting for your partner to send another message.

3.2 Generating a New Key Pair (STATION Certificate)

You can generate a new key pair (which can later be assigned to a station) using the Generate button.

The process is similar to generating a new keypair for a new trading station. You would provide:

  • a common name (CN)
  • identification details (organization/unit, address etc.)
  • a length for the key being generated
  • a validity period for the certificate (number of years forward); validity (NotBefore) starts from the actual time of generation.
  • a password for securely storing the generated private key

3.3 Renewing a (STATION) Certificate

A certificate may need to be renewed if:

  • it has expired (or is about to expire), or
  • it has to be reissued (e.g. converting a self-signed certificate into a CA-issued, trusted one)

Note: In any case, your partner(s) need to configure the renewed certificate on their end; otherwise you will not be able to decrypt messages that they send, and they will not be able to verify message/MDN signatures generated by you. Usually this configuration update has to be performed in a mutually agreed time frame, to keep both ends consistent and prevent breaking of live traffic.

The ‘Renew certificate’ button displayed for STATION type certificates, allows you to perform a renewal in two ways:

3.3.1 Self-signed

Here, the public key of the certificate is signed using its own private key (using the same distinguished name (DN) attributes that are currently assigned to that certificate). This results in a self-signed certificate, whose validity (NotBefore and NotAfter) is set to the timestamps that you specify during renewal.

Certificate Renewal
Certificate Renewal

Note:

  • If you set NotBefore to a future timestamp, the new certificate will not be usable (valid) until that time. Please double-check and refine the automatically selected timestamp as appropriate.
  • Just like any other self-signed certificate, the renewed certificate will need to be installed and trusted on your partner’s end before AS2 communication can be carried out successfully.

3.3.2 CA-issued (trusted)

Here you can merge a trusted (CA-issued) certificate into an existing keypair. This is useful if you decide to convert an existing self-signed keypair (which is already actively being used) into a trusted set, most commonly due to security/compliance requirements of trading partners/systems.

Because a CA is involved, the renewal flow here is not contiguous:

  1. AS2 Gateway generates a certificate signing request (CSR) file for the key pair (via the Export Now button on the dialog, or the .csr download option on the certificate list entry).
  2. You submit the CSR file to the CA, who then issues a trusted certificate for it.
  3. You upload and submit the received certificate via the Renew button on the renewal dialog; AS2 Gateway associates the certificate with the original key pair.

Step 3 can be performed separately (independent of the CSR download).

Note: Currently, a certificate renewal immediately affects the corresponding trading station’s AS2 traffic. We are working on providing a schedule option for certificate updates; when this becomes available, you will be able to set/configure exactly when the renewed certificate will get applied to production traffic, in order to coordinate the update with your trading partner easily and automatically.