12. Support for OpenSSL Engines¶
OpenSSL® engines allow you to define custom implementations for cryptographic operations. When you load an engine, OpenSSL will call the cryptographic functions defined by the engine instead of its default builtin functions. The Security Plugins support the option of using an OpenSSL engine, enabling you to use optimized cryptographic libraries, add support for custom hardware acceleration, etc.
When set, the
openssl_engine property defines the OpenSSL engine to be used. The value of this property for the first DomainParticipant of the application will be the value for all other DomainParticipants in the application. Setting this property to a different value for subsequent DomainParticipants will not be effective and will be silently ignored.
Connext is only tested with the OpenSSL builtin engine. Modifying or Configuring OpenSSL engines may result in deviations from tested scenarios. Support for custom OpenSSL configurations may require a support contract with RTI Professional Services.
12.1. Properties for Configuring OpenSSL Engines¶
Table 12.1 lists the properties that you can set to configure OpenSSL engines. These properties are configured through the DomainParticipant’s PROPERTY QosPolicy (see QoS Properties).
Property Name (prefix with
Property Value Description
One or more dynamic libraries, each implementing an OpenSSL engine.
If this property value is not set, the Security Plugins will use native OpenSSL code with its default engine.
Otherwise, you must set this value to the filename, excluding the
When specifying multiple libraries, they must be separated by a semicolon
Failure to load any of the engines will result in failure to create the DomainParticipant.
Each engine may implement a different set of security functions. For example, one engine may implement certificate management, while another engine may implement cryptographic operations such as encryption, HMAC, and Diffie-Hellman. For any security functions needed by the security plugins but not implemented by any of the engines, their builtin OpenSSL implementations will be invoked.
Default: not set, meaning that the OpenSSL builtin engine will be used.
The format of the private key specified by
The value of this property can be one of the following:
Assuming you used
com.rti.serv.secureas the alias to load the plugin. If not, change the prefix to match the string used with
com.rti.serv.load_plugins, followed by the
12.2. Advanced Concepts¶
12.2.1. Support for Engine Control Commands¶
You may use properties to invoke a sequence of
ENGINE_ctrl_cmd_string() function calls (see Issuing control commands to an ENGINE from OpenSSL Documentation). These properties are configured through the DomainParticipant’s PROPERTY QosPolicy (see PROPERTY QosPolicy (DDS Extension) in the Core Libraries User’s Manual). The XML format of the properties in the QoS Profile is as follows, assuming that you used
com.rti.serv.secure as the alias to load the Security Plugins (see Table 9.1):
<domain_participant_qos> <property> <value> <element> <name>com.rti.serv.secure.openssl_engine</name> <value>[engineName]</value> </element> <element> <name>com.rti.serv.secure.openssl_engine.[engineName].[cmdName1]</name> <value>[arg1]</value> </element> <element> <name>com.rti.serv.secure.openssl_engine.[engineName].[cmdName2]</name> <value>[arg2]</value> </element> ... </value> </property> </domain_participant_qos>
The above properties will result in the following code being called by the Security Plugins upon loading the engine:
ENGINE_ctrl_cmd_string(engineIdentifiedBy[engineName], [cmdName1], [arg1], 0); ENGINE_ctrl_cmd_string(engineIdentifiedBy[engineName], [cmdName2], [arg2], 0);