The following topics provide details about how SCX is implemented in Activator.
SCX request messages, which are XML documents, do not contain explicit indications of how a certificate is to be used by the receiving partner. The receiver of an SCX message is supposed to find a matching certificate that is already in use for the trading relationship with the sender of the message to determine how the new certificate is to be used. A matching certificate is a certificate with exactly the same issuer name, subject name, key usage and extended key usage. Even if a matching certificate is found it may not be obvious how exactly to use the new certificate.
Activator applies rules to determine the intended usage of certificates received in SCX messages. First, a default set of usages is determined in the following order:
Once a received certificate's default usages are determined, Activator looks for matching certificates already in use in the trading relationship between the partner and community that sent and received the new certificate. If no matching certificate is found, it is assumed the certificate is intended to be used for the default purposes as just determined.
If matching certificates are found, they are arranged in order from newest to oldest. Additionally, for each matching certificate the following checks are made to possibly limit the default usage of the new certificate:
If applying these rules for a matching certificate does not eliminate all potential usages of the new certificate, the matching object is deemed to be the matching certificate, and the limited certificate usages are used as the intended certificate usages.
If after going through all the matching certificates no potential certificate usages are found, the originally determined default certificate usages are used, and it is assumed there is no matching certificate.
The positive or negative receipt (EERP or NERP) to an OFTP SCX message is used to indicate whether the sent certificate has been accepted or rejected. If Activator sends SCX messages to a system not configured to automatically accept received SCX certificates, a user may see OFTP messages in the “waiting for receipt” state for extended periods in Activator. This should not be a problem if the resend time on the sending system is set appropriately to avoid resending the original message before a user on the receiving system has had time to accept or reject the certificate.
OFTP SCX messages are never signed or encrypted and their receipts (EERPs and NERPs) are never signed. Regardless of the collaboration settings, Activator never signs or encrypts an outgoing SCX message. It also does not request a signed receipt for such a message. Regardless of the configured message validation rules, Activator always accepts SCX messages and receipts that are not signed or encrypted.
The Odette community prefers CA-issued certificates and discourages self-signed certificates. But Activator supports both. When an SCX message is used to send a CA-issued certificate, only the end-entity certificate is contained in the message. When Activator receives such a message, the CA certificates necessary to construct the complete path for the received end-entity certificate must already be in its certificate store. If not already present, you can copy the required CA certificates to the conf\certs directory. This is the repository of well-known CA root and intermediate certificates.