Gazebo‑ROS 2 Control Plugin and DDS Security: Handling Expired Credentials

Direct answer

No. gazebo_ros2_control should not implement its own DDS participant reset for X.509 credential renewal. DDS Security authentication and re-handshake are middleware responsibilities, and the plugin has no supported hook to force a participant rebuild. A plugin-side reset would duplicate vendor logic and risks destabilizing the simulation control loop.

With current ROS 2 distributions, restoring topic exchange after a credential renewal is done by restarting the process that owns the DomainParticipant. For Gazebo, that is the simulator process that hosts gazebo_ros2_control. Users should rely on external orchestration to restart Gazebo / ROS 2 nodes, not on a Gazebo-side reconnection mechanism.

Confirmed facts

• DDS Security validates X.509 identity certificates at participant authentication time. Authentication is performed by the DDS vendor security plugin, not by rcl or the ROS 2 control plugin.
• There is no standard rcl/rmw API to trigger re-authentication of an existing DomainParticipant. Recreating a participant generally requires recreating the process that owns it.
• Gazebo does not expose a reconnection hook for gazebo_ros2_control. The plugin relies on the underlying DDS security layer which reports authentication failure and does not trigger a reconnection on its own.

Likely explanation

The authentication failure you see after renewal is the DDS security plugin rejecting or expiring the old identity. Discovery and topic matching occur below the rcl/rmw layer, so the ROS 2 node embedded in Gazebo has no standard way to re-handshake without a new participant. Behavior is vendor-dependent: Fast DDS and Cyclone DDS differ in how they handle credential reload and re-authentication, and certificate hot-reload is not uniformly exposed through rcl.

Recommended division of responsibility

1. Keep credential renewal and reconnection orchestration outside Gazebo. Use a launch system, systemd unit, or lifecycle manager to renew credentials and restart affected nodes.
2. Treat Gazebo as one of those nodes. Restart the Gazebo process after credentials are renewed to obtain a fresh DomainParticipant with the new identity.
3. Avoid embedding participant-reset hacks in gazebo_ros2_control. Destroying the node mid-simulation can break controller timing and leave controllers in a bad state.

Verification steps for your stack

• Set SROS2/DDS Security keystores with a short-lived test certificate. Run Gazebo with gazebo_ros2_control publishing joint states and monitor with ros2 topic echo /joint_states.
• Renew the certificate while the simulation is running. Observe whether topic exchange resumes without restart.
• Enable DDS security logging for your rmw implementation to confirm whether a re-authentication attempt occurs after renewal or whether the failure is terminal for that participant.
• Repeat with the other rmw implementation by switching RMW_IMPLEMENTATION between Fast DDS and Cyclone DDS to confirm vendor-specific behavior.
• Confirm recovery: restart only the Gazebo process and verify topic exchange resumes. This establishes process restart as the working remediation for your stack.

Note: expired-credentials behavior may also depend on governance/permissions documents, not only the identity certificate. Check all three artifacts before concluding reconnection is impossible.

One missing detail that changes the recommendation: which RMW implementation and ROS 2 distribution you are using, e.g., RMW_IMPLEMENTATION=rmw_fastrtps_cpp vs rmw_cyclonedds_cpp on Rolling/Jazzy/Humble. Hot-reload support varies by rmw version and is not uniformly exposed through rcl.