Driver signing
TwinCAT C++ modules must be signed with a certificate so that they can be executed.
The signature ensures that only C++ software whose origin can be traced is executed on productive systems.
For test purposes, certificates that cannot be verified can be used for signing. However, this is only possible if the operating system is in test mode so that these certificates are not used on productive systems.
Engineering requires no signing Only the execution requires certificates - the engineering does not. |
There are two ways to load modules. For this purpose, different certificates are used for signing:
- TwinCAT: the C++ modules are loaded by the TwinCAT runtime system and must be signed with a TwinCAT user certificate.
- With TwinCAT 3.1. 4024 and higher, this procedure is also available.
- This procedure is required to perform new functions such as Versioned C++ Projects and thus also the Online Change.
- Required for TwinCAT/BSD.
- (For <4024.0, no longer recommended for new projects. Existing projects should be migrated)
Operating system: the C++ modules are loaded as normal kernel drivers and must therefore also have a signature. - With TwinCAT 3.1. 4022 or earlier, only this procedure is available.
- Windows 7 (Embedded) x86 (32bit) does not require signing.
- Cannot be used with TwinCAT/BSD.
Since a published module should be executable on various PCs, signing is always necessary for publishing.
Organizational separation of development and production software
Beckhoff recommends working organizationally with (at least) two certificates.
- A certificate which is not countersigned, thus the test mode is needed for the development process. This certificate can also be issued individually by each developer.
- Only the software that has passed the corresponding final tests is signed by a countersigned certificate. This software can thus also be installed on machines and delivered.
Such a separation of development and operation ensures that only tested software runs on productive systems.