System requirements for Maximo APM – Asset Health Insights Before you install Maximo APM – Asset Health Insights feature pack 7.6.1, ensure that Maximo Asset Management version 22.214.171.124 or
Sterling B2B Integrator - Initializing a Subscriber
After a contract has been defined, the corresponding bank sets up the partner and subscriber (user) master data in the Subscription Manager database through the import function.
The bank does not yet have the user’s public certificates. Transmission of the user’s public certificates to the bank’s system is required to initialize the user.
There are three order types used for subscriber initialization: H3K, INI, and HIA. H3K is the simplest and transmits all three public certificates at the same time. However, H3K cannot be used in all cases, such as if trusted keys are used or with protocol version H003. If you cannot, or prefer not to, use H3K, you can use INI and HIA together to transmit the public certificates.
|INI||H003, H004||Bank-technical key|
With protocol version H004, you can use order type H3K, which simplifies and automates the procedure, essentially combining INI and HIA into a single step. Trusted keys are not supported for H3K, and at least the bank technical key used for the ES must be a certificate issued by a Certification Authority (CA). The remaining two certificates for identification and authorization and for encryption can be self-signed certificates. H3K requires no initialization letters.
Use INI and HIA for initialization with non-CA issued certificates or trusted keys, or with protocol version H003.
INI and HIA
The supported versions for the Electronic Signature (ES), encryption, and identification and authentication signature are components of the bank parameters. The user’s bank-technical key must be newly-generated if the user does not have a suitable bank-technical key or does not want to use an existing bank-technical key for the new bank connection. The same applies for the encryption key and the identification and authentication key.
- INI – Sends the public bank-technical key
- HIA – Sends the public identification and authentication key and the public encryption key
When the user is first assigned to a partner, the status of the user is New. If the user sends only the INI request to the bank, the status is changed to Partly Initialized (INI). If the user sends only the HIA request to the bank, the status is changed to Partly Initialized (HIA). After the user sends both the INI and HIA requests to the bank, the status is changed to Initialized. The user mails signed initialization letters containing the INI and HIA keys to the bank. When the bank receives the initialization letters for INI and HIA, it verifies the hash values in the certificates against its database. After successful verification, the status of the user is set to Ready, indicating that the user can now transact with the bank. The user then downloads the bank’s public certificates using the HPB system order type.
The subscribers can retrieve information stored by the bank using the HKD and HTD order types after the user status is set to ‘Ready’.
A bank must create the encryption, and authentication and identification bank certificates in the Sterling B2B Integrator database.
To create a self-signed certificate, complete the following steps:
- Log in to Sterling B2B Integrator.
- From the menu, select .
- In the System Certificates page, click Go next to Create Self-Signed Certificate.
- In the Name field, enter the name of the self-signed certificate. This must be a unique and meaningful name.
- In the Organization field, enter the name of the originating organization.
- From the Country drop-down list, select the country or origin of the self-signed certificate.
- In the E-mail field, enter the e-mail address of the person responsible for the certificates in the organization.
- Click Next.
- In the Specification page, enter the serial number that you want to assign to the self-signed certificate, in the Serial Number field.
- In the Duration field, enter the number of days for which the self-signed certificate is valid.
- In the List of IP addresses Separated by Comma field, specify the IP addresses.
- In the List of DNS Names Separated by Comma field, specify the DNS names.
- From the Key Length drop-down list, select a key length (512, 1024, or 2048).
- From the Signing Algorithm drop-down list, select the signing algorithm option:
- SHA1withRSA - Use this for certificates used with EBICS transactions and TLS layer encryption (SSL).
- SHA256withRSA (Recommended) - Use this for certificates used with EBICS transactions.
- Next to Validate When Used check box, select the validation option:
- Validity – Verifies if the dates in the validity period of the certificate are still in effect or not. If the dates are not in effect, the certificate is not used.
- Auth Chain – Constructs a chain of trust for certificates that are not self-signed. If a chain of trust cannot be constructed using valid certificates, the certificate is not used. If the certificate is self-signed, this option verifies only the certificate signature.
- Select the Set the Certificate Signing bit check box.
- Click Next.
- In the Confirm page, verify the information pertaining to the self-signed certificate, and click Finish.
- Click Return to return to the System Certificates page.The bank certificates are now available for viewing and editing under Administration menu of Sterling B2B Integrator.under the
A bank verifies the INI and HIA requests from a user before accepting them. The bank checks the relationship between the user ID and the partner ID and validates the user state. On successful verification, the user's public certificate is automatically added to the EBICS Banking Server repository.
Navigate to Administration menu of Sterling B2B Integrator to view the newly added certificates.under the
After both the INI and HIA requests are processed successfully, the bank changes the status of the user to Initialized
After a bank receives the INI and HIA order types, the corresponding user's status is set to Initialized. You can validate the hash value of the certificates that are sent by the user in the initialization letters against the Subscription Manager database. On successful validation, the status of the user is set to Ready. EBICS Server supports RSA Keys and X509 Certificates.
To validate a subscriber key, complete the following steps:
- Log in to Sterling B2B Integrator .
- From the Administration menu, select EBICS > Utilities > Subscriber Keys Validation.
- In the Subscriber Keys Validation page, provide values for the fields listed in the following table:FieldDescription
Partner ID Required. Specify the partner ID. To select from a list of partner IDs, click the Lookup icon next to the Partner ID field. User ID Required. Specify the user ID. To select from a list of user IDs, click the Lookup icon next to the User ID field. Identification and Authentication Key Hash Value (in Hex format) Optional. If the certificate is CA-signed, specify the identification and authentication key hash value in hex format. Hash Algorithm Required. Select the hash algorithm of the identification and authentication key hash value. Valid values are:
- SHA256 (default)
Encryption Key Hash Value (in Hex format) Optional. If the certificate is CA-signed, specify the encryption key hash value in hex format. Hash Algorithm Required. Select the hash algorithm of the encryption key hash value. Valid values are:
- SHA256 (default)
Electronic Signature Key Hash Value (in Hex format) Optional. If the certificate is CA-signed, specify the electronic signature key hash value in hex format. Hash Algorithm Required. Select the hash algorithm of the electronic signature key hash value. Valid values are:
- SHA256 (default)
Certificate type Required. Specify the Certificate type - Keys or X509 as required.
- Click Reset if you want to clear the existing values and enter new values.
- Click Validate.
A user downloads all the public certificates (identification and authentication signature, bank-technical signature, and encryption) from the corresponding bank through the order type HPB. The user can download the public bank certificates only after the user status is set to Ready.
The following steps summarize a bank's handling of the HPB order type:
- A bank receives an HPB request from a user.
- The bank conducts an authentication check of the user's request.
- The bank supplies the requested HPB order data, that is, the bank's public certificates, as a response to the user for the user to download the public certificates.
When the incoming client certificate is self-signed, the EBICS Banking Server validates the date.
- Online Certificate Status (OCSP) or Certificate Revocation List (CRL) – If the certificate status is revoked, the EBICS Banking Server suspends the user. By default, EBICS Banking Server validates OCSP. If OCSP is successful, the server does not validate CRL. If you want the server to validate CRL, set the ebicsserver.ocsp parameter to false in the ebics_server.properties file.
- Date – validity of the certificate
- Chained signature – the validity of the Certificate Authority
The Online Certificate Status Protocol (OCSP) is a set of ASN.1 defined data structures for requesting and receiving information about certificate revocation status. These data structures can be sent and received by many transport protocols in principle. In practice, HTTP is used. An OCSP client sends questions and processes responses.
- Set up the certificate authority in the server database. Ensure that the issuer certificate has been checked in as a CA certificate.
- For UNIX, run the following command: ./ManageCertAuthority.sh –a VPCA admin SHA1 <ca_cert_id> always,end-user none
- For Windows, run the following command: ManageCertAuthority.cmd –a VPCA admin SHA1 <ca_cert_id> always,end-user none
- Set up basic profile with HTTP as the protocol and the OCSP responder as the End Point.
- Set up OCSP responder for the authority in the server database.
- For UNIX, run the following command: ./ManageOCSPResponder.sh –a VPCA admin SHA1 <ca_cert_id> <resp_cert_id> no <time_to_live_in_sec> <profile_id> HTTPClientSend 3600 no no
- For Windows, run the following command: ManageOCSPResponder.cmd –a VPCA admin SHA1 <ca_cert_id> <resp_cert_id> no <time_to_live_in_sec> <profile_id> HTTPClientSend 3600 no no
- Each OCSP respond is cached in the server based on the <time_to_live_in_sec> value. Subsequent similar OCSP requests make use of the cached record as long as the record is valid.
Certificate Revocation List (CRL) validation occurs when OCSP validation has failed or the server has been configured not to validate OCSP.
Prior to validating CRL, configure the server to run a scheduled business process to download CRL from the CRL distribution point every four hours. You can obtain the CRL distribution point from the certificate authority website or from the certificate.
Use the GET_CRL_PROCESS business process to create a scheduled business process with necessary CRL distribution point and proxy settings.
If the server is unable to find the CRL of a certificate, the validation continues. If the certificate is revoked, the server suspends the user and no further transactions are allowed.
You can validate certificates by using different order types such as INI, HIA, FUL, or FDL.
INI and HIA
When processing the INI order type, the EBICS client sends its ES certificate to the server. When processing the HIA order type, the EBICS client sends its authentication and encryption certificates to the server.
The server validates the certificates for integrity before storing them in the server database. If all the certificates (ES, authentication, and encryption) are CA-signed and the user is configured as a signatory, the status of the user is automatically set to ‘Ready' after successful processing of the INI and HIA order types.
If any of the certificates is self-signed, the server validates the hash value of the certificate against the hash value stored in the initialization letter.
When processing the FUL order type, after the initialization phase, the transfer phase is asynchronous. The client can upload multiple segments of order data. The order data can be signed by multiple signatories. The signatory may not be the submitter of FUL.
If the Prevalidate parameter in the server is set to ‘On', the server unpacks and validates the ES certificates in the initialization phase before the client sends the order data. A partial validation (OCSP or CRL) is done at the transfer phase.
If the Prevalidate parameter in the server is set to ‘Off', the server does not unpack the ES certificates and validates the certificates at the transfer phase.
The server validates the ES certificates that are used to sign the order data. If the ES certificate of the FUL submitter is not used to sign the order data, the server does not validate the ES certificate.
When processing the FDL order type, the server packs the order data to enable the client to download the order data. The authentication certificate is validated at each phase and the encryption certificate is validated at the initialization and transfer phases.
The encryption certificate of the client is used to encrypt the order data and is not signed. Therefore, the server performs a full validation on the authentication and encryption certificates.
Share Blog Post
Installing Maximo APM – Asset Health Insights 7.6.1 Before you install the Maximo® APM – Asset Health Insights 7.6.1 feature pack, ensure that the enterprise