Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

4.3. Rule Package Signing


4.3.1. Rule Package Signing

Rule packages are not signed by default; however, Red Hat recommends enabling rule package signing in production environments. Signing rules packages ensures that the packages cannot be corrupted or tampered with during download from the JBoss Enterprise BRMS Platform server to client applications.
Rule packaging signing is implemented with public key cryptography. Packages are signed with a private key that can only be verified with the matching certificate. The private key is stored in the keystore and is used by the server to automatically sign each package. The public certificate is made available to the client applications in a keystore referred to as a truststore. The certificate in the truststore is used to verify the authenticity of the signed packages. Rule packages that are corrupted or modified during download will be rejected by the client because they no longer match the certificate.

4.3.2. Configuring the Server for Rule Package Signing

Before configuring the server for rule package signing with this process, it is necessary to do the following:
  • Create a private signing key and a corresponding public digital certificate.
  • Make the private signing key and the digital certificate available to the server in keystores.
  • Configure the server to use the keystores.

Procedure 4.6. Configure Rule Package Signing

  1. Use the keytool command to create the private keystore:
    keytool -genkey -alias ALIAS -keyalg RSA -keystore PRIVATE.keystore
    The -alias parameter specifies the name used to link the related entities in the keystore. Use the same alias for each of these steps. The alias is not case-sensitive. The -keystore parameter supplies the name of the file which will be created to hold the private key.
    keytool will prompt you for identifying information as well as two passwords. The first password, the keystore password, secures the keystore. The second password, the key password, secures the key that is being created.
    [localhost ]$ keytool -genkey -alias BRMSKey -keyalg RSA -keystore PrivateBRMS.keystore
    Enter keystore password:  
    Re-enter new password: 
    What is your first and last name?
       [Unknown]:  John Smith
    What is the name of your organizational unit?
       [Unknown]:  Accounts
    What is the name of your organization?
       [Unknown]:  ACME INC
    What is the name of your City or Locality?
       [Unknown]:  Capital City
    What is the name of your State or Province?
       [Unknown]:  CC
    What is the two-letter country code for this unit?
       [Unknown]:  US
    Is CN=John Smith, OU=Accounts, O=ACME INC, L=Capital City, ST=CC, C=US correct?
       [no]:  yes
    Enter key password for <BRMSKey>
       (RETURN if same as keystore password):  
    Re-enter new password:
    
    Copy to Clipboard Toggle word wrap
  2. Use the keytool command to create a digital certificate:
    keytool -export -alias ALIAS -file CERTIFICATE.crt -keystore PRIVATE.keystore
    Use the same alias and keystore as the previous step. The -file parameter is the filename of the new certificate that will be created. The -keystore parameter supplies the filename of the private keystore.
    Enter the keystore password at the prompt.
    [localhost ]$ keytool -export -alias BRMSKey -file BRMSKey.crt -keystore PrivateBRMS.keystore
    Enter keystore password:  
    Certificate stored in file <BRMSKey.crt>
    Copy to Clipboard Toggle word wrap
  3. Use the keytool command to import the digital certificate into a keystore:
    keytool -import -alias ALIAS -file CERTIFICATE.crt -keystore PUBLIC.keystore
    This will create a new keystore, the truststore, which contains the digital certificate. The truststore makes the digital certificate available to client applications.
    [localhost ]$ keytool -import -alias BRMSKey -file BRMSKey.crt -keystore PublicBRMS.keystore
    Enter keystore password:  
    Re-enter new password: 
    Owner: CN=John Smith, OU=Accounts, O=ACME INC, L=Capital City, ST=CC, C=US
    Issuer: CN=John Smith, OU=Accounts, O=ACME INC, L=Capital City, ST=CC, C=US
    Serial number: 4ca0021b
    Valid from: Sun Sep 26 22:31:55 EDT 2010 until: Sat Dec 25 21:31:55 EST 2010
    Certificate fingerprints:
       MD5:  31:1D:1B:98:59:CC:0E:3C:3F:57:01:C2:FE:F2:6D:C9
       SHA1: 4C:26:52:CA:0A:92:CC:7A:86:04:50:53:80:94:2A:4F:82:6F:53:AD
       Signature algorithm name: SHA1withRSA
       Version: 3
    Trust this certificate? [no]:  yes
    Certificate was added to keystore
    Copy to Clipboard Toggle word wrap
  4. The private keystore needs to be kept in a secure location where only the JBoss Enterprise BRMS Platform server is able to access it. This could be on the same machine or in a secured network location that is available to that machine.

    Important

    The JBoss Enterprise BRMS Platform is not able to supply authentication credentials to network resources. If the private keystore is stored in a secure network location, then any authentication procedures must be performed on the behalf of the JBoss Enterprise BRMS server to make the private keystore available to it. For example, the operating system can authenticate and mount a file share that holds the private keystore as a local directory for the JBoss Enterprise BRMS Platform server to access.
  5. The truststore needs to be accessible to client applications. This can be done by putting the truststore on network share or hosting it on a webserver.
  6. The Drools serialization system properties need to be set on the server. These are the properties that store the information required to access the keystores. Because JBoss Enterprise BRMS Platform also contains client components, both the private keystore and truststore properties have to be set on the server. The properties only need to be set in one location and will be available to all applications running on the same application server instance regardless of where they are set.
    Set the serialization properties by editing the preferences.properties file, which is located in server/profile/deploy/jboss-brms.war/WEB-INF/ to include the following properties:
    drools.serialization.sign=true
    drools.serialization.private.keyStoreURL=file:///opt/secure/PrivateBRMS.keystore
    drools.serialization.private.keyStorePwd=storepassgoeshere
    drools.serialization.private.keyAlias=BRMSKey
    drools.serialization.private.keyPwd=keypassgoeshere
    drools.serialization.public.keyStoreURL=file:///opt/public/PublicBRMS.keystore
    drools.serialization.public.keyStorePwd=keypassgoeshere
    Copy to Clipboard Toggle word wrap
  7. The keystore password is currently stored in plain text.
    Refer to https://access.redhat.com/kb/docs/DOC-47247 for instructions to mask the keystore credentials.

4.3.3. Configuring the Client for Rule Package Signing

The procedure below describes the process of configuring the client applications for for Rule Package Signing. This involves setting several properties on the client. The properties can be set programatically using the System.setProperty method. The class org.drools.core.util.KeyStoreHelper class contains several constants that represent these properties.
Before performing this task, you require the following:
  • A JBoss Enterprise BRMS Platform Server already installed and correctly configured for Rule Package Signing.
  • The URL for the truststore that contains the Digital Certificate used by the JBoss Enterprise BRMS Platform Server.
  • The password for the truststore, if one is set.

Procedure 4.7. Client Configuration for Rule Package Signing

  1. Enable signing by setting the drools.serialization.sign property to true.
    System.setProperty( KeyStoreHelper.PROP_SIGN, "true" );
    Copy to Clipboard Toggle word wrap
  2. Set the drools.serialization.public.keyStoreURL property to the URL where the TrustStore is located. If the TrustStore is in the classpath of the client then this can be done using the getClass().getResource() method.

    Example 4.1. When the TrustStore is located on the client's classpath

    URL trustStoreURL = getClass().getResource( "BRMSTrustStore.keystore" );
    System.setProperty( KeyStoreHelper.PROP_PUB_KS_URL, trustStoreURL.toExternalForm() );
    Copy to Clipboard Toggle word wrap

    Example 4.2. When the TrustStore is located on a webserver

    URL trustStoreURL = new URL("http://brms.intranet/resources/BRMSTrustStore.keystore" );
    System.setProperty( KeyStoreHelper.PROP_PUB_KS_URL, trustStoreURL.toExternalForm() );
    Copy to Clipboard Toggle word wrap

    Example 4.3. When the TrustStore is located on the local file system

    URL trustStoreURL = new URL("file:///mnt/fileserve/rules-server/BRMSTrustStore.keystore" );
    System.setProperty( KeyStoreHelper.PROP_PUB_KS_URL, trustStoreURL.toExternalForm() );
    Copy to Clipboard Toggle word wrap
  3. Set the drools.serialization.public.keyStorePwd property to the password for the truststore. This is only required if a password is required to access the truststore.
    System.setProperty( KeyStoreHelper.PROP_PUB_KS_PWD, "sekretPasswordHere" );
    Copy to Clipboard Toggle word wrap

Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat