Processor for generating a digital signature based on asymmetric key cryptography.

The incoming payload is used as input for producing a binary signature. The signing algorithm is specified by the user. Non-binary payloads will be converted to binary before being processed.


Name Summary


The selected signing algorithm. Supported algorithms: SHA1withDSA, SHA1withRSA, SHA256withDSA, SHA256withRSA. See standard JDK signature algorithms. Required.


The config key for the encryption based message signing. Required.


Optional, descriptive name for the processor.


Required identifier of the processor, unique across all processors within the flow. Must be between 3 and 30 characters long; contain only lower and uppercase alphabetical characters (a-z and A-Z), numbers, dashes ("-"), and underscores ("_"); and start with an alphabetical character. In other words, it adheres to the regex pattern [a-zA-Z][a-zA-Z0-9_-]{2,29}.


Optional set of custom properties in a simple jdk-format, that are added to the message exchange properties before processing the incoming payload. Any existing properties with the same name will be replaced by properties defined here.


Whether the incoming payload is available for error processing on failure. Defaults to false.


Name Summary


Strategy for describing how a processor’s message is logged on the server.


Strategy for archiving payloads.


Strategy that customizes the conversion of an incoming payload by a processor (e.g., string to object). Should be used when the processor’s default conversion logic cannot be used.



To correctly use this processor, please take note of the following:

  • The config key must resolve to a Tls secret.

  • This processor will fail unless the Tls secret contains a valid client key store.

  • The client key store is valid if it contains a private client key.

  • The private client key is used for signing.

  • Typically, the key store and private key passwords are identical. If not, you can set the private key password using the Tls secret property: clientKeyPassword.

  • If the keystore contains more than one key entry, the clientKeyStoreAlias must disambiguate the client key store entry name.

In summary, the following Tls secret properties are required when used for this processor:

  • clientKeyStore

  • clientKeyStorePassword