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 two standards:
Each standard is for trading partners to exchange public-key certificates and replace certificates that are about to expire, have been compromised or need replacing for some other reason.
The primary purpose of CEM and SCX is to replace certificates with new ones. CEM is not intended as a way to distribute certificates to partners the first time. SCX in theory can be used to send certificates to partners the first time, but that is not supported in Activator.
The user interface uniformly handles CEM and SCX through:
The CEM standard encompasses certificate exchanges between partners who use the AS1, AS2 and AS3 message protocols. Activator supports CEM for AS1, AS2, AS3 and also the Secure File message protocol. The protocols are supported for Activator communities and partners who use Activator or a third-party interoperable trading engine.
Activator supports SCX between partners who use Odette File Transfer Protocol version 2 (OFTP2) trading delivery exchanges only. This support is for Activator communities and partners who use Activator or a third-party interoperable trading engine.
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 or SCX by having an active OFTP2 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 and SCX.
If the community chooses not to send any CEM or SCX 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, else the new certificate is installed automatically. CEM defines this “respond by date.” SCX, however, does not support this, so the date is not included in any SCX messages. But the respond by date is still used to trigger the automatic installation of the new certificate if not all partners have responded by that date and time. Once every partner has responded to accept, the certificate is installed automatically, and any previously scheduled installation is cancelled.
Certificates used for the ordinary purposes of signing, encryption and SSL can be sent in CEM and SCX requests for acceptance by partners. There are some variations in the way Activator handles certificates slated for different uses that you should know about.
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.
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:
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.
CEM is a draft standard of the Internet Engineering Task Force (IETF). The IETF draft is available at the following URL:
http://tools.ietf.org/html/draft-meadors-certificate-exchange-14
SCX is a recommendation of Odette and is documented in the “OFTP2 Implementation Guidelines” available on the Odette forum at: