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.