Automatic replacements

Activator can send end-entity certificates to a community’s partners to replace certificates. Activator can send partners a replacement once a community has generated or imported a new self-signed certificate or imported a new CA certificate. Partners can signal acceptance or rejection of the new certificate. Administrators can make the process fully or semi-automatic.

Activator supports Certificate Exchange Messaging (CEM)for EDIINT trading. This enables trading partners to exchange public-key certificates and replace certificates that are about to expire, have been compromised, or need to be replaced for other reasons.

The user interface uniformly handles CEM through:

  • Sending certificate exchange messages
  • Managing sent certificate exchange trust requests
  • Managing received certificate exchange requests

Scope of CEM support

The CEM standard encompasses certificate exchanges between partners who use the AS2 message protocol. Activator supports CEM for AS2 . The protocols are supported for Activator communities and partners who use Activator or a third-party interoperable trading engine.

Overview of exchange process

After a trading relationship has been established, a community may get another certificate and public-private key pair, either by generating a self-signed certificate or importing a P12 or PFX file. The certificate can be for use by the community for signing and encrypting messages or use as an SSL or TLS server certificate. Obtaining a new certificate triggers Activator to check whether the community supports CEM by having an active EDIINT delivery exchange. It also checks whether any of the community’s partners have an active default corresponding delivery exchange. If so, the community has the option of sending certificate exchange messages containing the new certificate to any or all partners. The UI displays the partners grouped by CEM.

If the community chooses not to send any CEM certificate exchange messages, the certificate is installed normally. However, if the community chooses to send any certificate exchange messages, the UI stops short of installing the new certificate and just adds it to the certificate store and the proper key store.

When selecting the partners to receive certificate exchange messages, the community sets a date and time for partners to respond, or else the new certificate is installed automatically. CEM defines this “respond by date.” Once every partner has responded to accept, the certificate is installed automatically, and any previously scheduled installation is cancelled.

Types of certificates in requests

Certificates used for the ordinary purposes of signing, encryption and SSL can be sent in CEMrequests for acceptance by partners. There are some variations in the way Activator handles certificates slated for different uses that you should know about.

Encryption

When a community sends a request for a new encryption certificate, the community must be prepared immediately to receive messages from partners encrypted with the new certificate and the old certificate the new certificate is intended to replace. Activator handles this without user intervention. Upon receiving an encrypted message, Activator determines the public key used to encrypt and uses the proper private key from its key store to decrypt.

Signing and SSL

A community uses a signing certificate to sign outbound messages. SSL certificates are used to authenticate a client or server.

When a community sends a request for a new signing or SSL certificate, the community does not implement the certificate unless one of the following conditions is met:

  • The respond-by date in the request has passed and no partners have sent a response rejecting the certificate. This means absent any responses — positive or negative — by the respond-by date, the community implements the certificate when the respond-by date has passed.
  • On or before the respond-by date, all partners have returned responses accepting the certificate. If all partners respond positively before the respond-by date, the community implements the certificate when the final positive respond has been received.

If only one partner sends a response rejecting the certificate, the community does not implement the certificate.

Moreover, upon accepting a new signing certificate, a partner must be able to accept messages from the community signed by either the new certificate or the old certificate the new certificate is intended to replace.

External resources

CEM is a draft standard of the Internet Engineering Task Force (IETF). The IETF draft is available at the following URL:

Related Links