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.

Table 1. Order types for subscriber initialization
Order types
Protocol
Keys/certificates
H3KH004
  • Bank Technical Key certificate for Electronic Signature (ES)
  • Identification and Authentication certificate
  • Encryption certificate
INIH003, H004Bank-technical key
HIAH003, H004
  • Identification and Authentication key
  • Encryption key
H3K

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.

The user transmits the public certificates to the financial institution through two independent communication paths:
  • 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:

  1. Log in to Sterling B2B Integrator.
  2. From the Administration menu, select Trading Partner > Digital Certificates > System .
  3. In the System Certificates page, click Go next to Create Self-Signed Certificate.
  4. In the Name field, enter the name of the self-signed certificate. This must be a unique and meaningful name.
  5. In the Organization field, enter the name of the originating organization.
  6. From the Country drop-down list, select the country or origin of the self-signed certificate.
  7. In the E-mail field, enter the e-mail address of the person responsible for the certificates in the organization.
  8. Click Next.
  9. In the Specification page, enter the serial number that you want to assign to the self-signed certificate, in the Serial Number field.
  10. In the Duration field, enter the number of days for which the self-signed certificate is valid.
  11. In the List of IP addresses Separated by Comma field, specify the IP addresses.
  12. In the List of DNS Names Separated by Comma field, specify the DNS names.
  13. From the Key Length drop-down list, select a key length (512, 1024, or 2048).
    Note: Use 2048 as the key length for EBICS.
  14. 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.
  15. 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.
      Note: Before you set a value to the validity period of the certificate, you should read and apply the best practice recommendations from the Microsoft PKI Quick Guide. For information about the best practice recommendations for using certificates, see http://www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part3.html.
    • 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.
  16. Select the Set the Certificate Signing bit check box.
  17. Click Next.
  18. In the Confirm page, verify the information pertaining to the self-signed certificate, and click Finish.
  19. Click Return to return to the System Certificates page.
    The bank certificates are now available for viewing and editing under Trading Partner > Digital Certificates > System under the Administration menu of Sterling B2B Integrator.

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 Trading Partner > Digital Certificates > System under the Administration menu of Sterling B2B Integrator to view the newly added certificates.

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:

  1. Log in to Sterling B2B Integrator .
  2. From the Administration menu, select EBICS > Utilities > Subscriber Keys Validation.
  3. In the Subscriber Keys Validation page, provide values for the fields listed in the following table:
    Field
    Description
    Partner IDRequired. Specify the partner ID. To select from a list of partner IDs, click the Lookup icon next to the Partner ID field.
    User IDRequired. 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 AlgorithmRequired. Select the hash algorithm of the identification and authentication key hash value. Valid values are:
    • SHA256 (default)
    • SHA1
    Encryption Key Hash Value (in Hex format)Optional. If the certificate is CA-signed, specify the encryption key hash value in hex format.
    Hash AlgorithmRequired. Select the hash algorithm of the encryption key hash value. Valid values are:
    • SHA256 (default)
    • SHA1
    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 AlgorithmRequired. Select the hash algorithm of the electronic signature key hash value. Valid values are:
    • SHA256 (default)
    • SHA1
    Certificate typeRequired. Specify the Certificate type - Keys or X509 as required.
    Note:

    By default, the rsaHashKeyCompliant property in the ui.properties file is false. To change the property, set rsaHashKeyCompliant to true and restart the server.

    When set to false, it generates the SHA-256 hash value for RSA keys, by concatenating the exponent with a blank character and the modulus in hexadecimal representation (using lower case letters). The resulting string is then converted into a byte array based on US ASCII code.

    When set to true it generates the SHA-256 hash value for RSA keys, by concatenating the exponent with a blank character and the modulus in hexadecimal representation (using lower case letters) without leading zero (as to the hexadecimal representation). The resulting string is then converted into a byte array based on US ASCII code.

    This property is also used while checking authentication tags in EBICS requests which are signed with RSA keys.

    When set to true, request tags without namespace: ds are parsed without throwing validation exception for namespace.

  4. Click Reset if you want to clear the existing values and enter new values.
  5. 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:

  1. A bank receives an HPB request from a user.
  2. The bank conducts an authentication check of the user's request.
  3. 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.

When the incoming client certificate is CA-signed or intermediate CA-signed, the EBICS Banking Server validates the following:
  1. 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.
  2. Date – validity of the certificate
  3. 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.

An OCSP responder answers questions and generates responses. To validate OCSP for an incoming client certificate, complete the following steps:
  1. 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
  2. Set up basic profile with HTTP as the protocol and the OCSP responder as the End Point.
  3. 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
  4. 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.
The server is now ready to validate OCSP for the incoming client certificate whose issuer matches the authority created. You can use the HTTPClientSend business process in Sterling B2B Integrator to send an HTTP request to the OCSP responder with a timeout value of 3600. You may have to configure the proxy settings in the HTTP Client adapter.
For more information about OCSP in Sterling B2B Integrator, see Online Certificate Status Protocol (OCSP) Support in.

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.

FUL

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.

Note: The server validates the authentication certificate at each phase regardless of the setting of the Prevalidate parameter. The client encryption certificate is not validated as it is not used in the FUL order type. The server uses its own private key to decrypt the order data.

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.

FDL

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.

Previous Topic

Sterling B2B Integrator - Configure EBICS Adapters and Services

Parent Topic

Sterling B2B Integrator - EBICS Server User

Next Topic

Sterling B2B Integrator - Accepting Test Flow from a User

Browse Categories

Share Blog Post

Pragma Edge (4.5/5)
4.5/5
Source: IBM

Recent Blog Posts - Read More

At Pragma Edge, we are a forward-thinking technology services provider dedicated to driving innovation and transformation across industries.

  • 12926 Gran Bay Pkwy W., Suite 220,
    Jacksonville, FL 32258
  • info@pragmaedge.com
  • +1 (848) - 999 - 9090
Linkedin Facebook-f X-twitter Youtube Instagram

What We Do

Industries

Products

Who We Are

Sterling Data Exchange

Thank you for submitting your details.

For more information, Download the PDF.

Get Solution Brief

PragmaEdge Universe | 2024

Thank you for the Registration Request, Our team will confirm your request shortly.

Invite and share the event with your colleagues 

Return to home page

IBM Partner Engagement Manager Standard

IBM Partner Engagement Manager Standard is the right solution
addressing the following business challenges

IBM Partner Engagement Manager Standard

IBM Partner Engagement Manager Standard is the right solution
addressing the following business challenges

IBM Partner Engagement Manager Standard

IBM Partner Engagement Manager Standard is the right solution
addressing the following business challenges

Pragma Edge - API Connect