Send a CEM or SCX request

Use this procedure to send a CEM or SCX request to one or more partners.

It is likely a community sends either a CEM or SCX request. However, if a community trades with some partners via EDIINT and some via OFTP2, the community could send CEM and SCX requests at the same time. If so, only one respond-by date could be selected for both request types.

1. In the user interface, launch the certificate wizard within a community to generate a self-signed certificate or import a CA certificate. See Add a certificate.
2. On the View certificate details page in the certificate wizard, select the use for the certificate (signing, encryption, SSL).
3. Select Send certificate exchange messages to partners.
4. If a the request is a CEM request, select the Respond by date and the partners to send the request. See the View certificate details page for CEM requests below. Go to step 6.
5. 
5. If the request is a SCX request, select the Respond by date and the partners to send the request. Select the type of SCX message to send. The type must be the same for all partners. See the View certificate details page for SCX requests below. The types to choose from follow this page illustration.
6. 
   • The SCX message types are:
     • Request – A request message contains one certificate that may match an existing certificate associated with the sender. The recipient can accept or reject the certificate, but either way must respond with one or more deliver messages containing its current certificates. This message can be used for an initial certificate exchange. Activator can send up to four deliver messages in response to a received request message, containing the recipient community’s current default signing certificate, default encryption certificate, default client authentication certificate and certificate for the first enabled TLS OFTP2 server. Only one deliver message is sent for any certificates that are duplicates of others.
     • Deliver – A deliver message contains one certificate that should match an existing certificate associated with the sender. The recipient should start using the new certificate some time before the current matching certificate expires. The recipient can accept or reject the certificate.
     • Replace – A replace message contains one certificate that should match an existing certificate associated with the sender. The recipient should start using the new certificate immediately and the current matching certificate should be removed from service immediately. When Activator receives a replace message the matching certificate is removed from service by disassociating it from the partner that sent the replace message. The matching certificate is not untrusted. The reason for this is that OFTP users most likely use CA-issued certificates, and when Activator trusts a CA-issued certificate, it frequently trusts the root CA certificate. It could be dangerous to untrust a root CA certificate, as this may affect other trading relationships.
6. To generate the request, click Finish to complete the process of generating or importing the certificate. This action also sends the request to the selected partners.
7. Open the Sent certificate exchange trust requests page to view the status of CEM and SCX requests. See Sent certificate exchange trust requests page.

Related topics

• Automatic replacements
• Types of CEM messages
• SCX details
• Track CEM and SCX requests