Signature libraries with the PLCnext Technology Toolchain
With the PLCnext Engineer release 2025.0 a new security feature was implemented which provides an option in the PLCnext Engineer to check libraries for trusted signatures. Here is, how to verify or add those signatures by means of PLCnext CLI, the Visual Studio® extension, or the Eclipse® add-in.
Verifying a signature by means of PLCnext CLI
The SecurityFramework.Cli.exe is installed next to the plcncli.exe and available within the terminal.
In addition to the signature validation, check the version of the PLCnext Engineer library (*.pcwlx) for correctness.
The path is set automatically with the Windows® installation, but after installing the Linux® version the path must be set manually. See installation.
- To verify a signature of a previously signed file by the PLCnext Technology Toolchain build, call this command:
SecurityFramework.Cli.exe verify --signature .\signatureT.p7s --inputFile .\integrity.xml --conformance Automatic --trustedCertificates ".\codeSigningRootCa.pem"
- For more information, especially in case of failures, add
--outputFile "log.txt"
to get detailed information.
Adding a signature to a PLCnext Engineer library...
...by means of PLCnext CLI
To add signatures to PLCnext Engineer libraries via command line, the plcncli deploy
command needs additional parameters.
The following decisions and information are needed:
-
Add the
--sign
parameter to activate signing in general. -
Add private key, public key and certificate of the signing authority; this can be done bei either adding a PKCS#12 archive with
--pkcs12 <path to pkcs12>
, or in separate steps:- Add the privat key PEM:
--privatekey <path to privatekey.pem>
- Add the public key PEM:
--publickey <path to publickey.pem>
- Add certificate files:
--certificates <path to *.crt>,<path to further optional *.crt>
- Add the privat key PEM:
-
Optional: Add the
--password <your private key password>
parameter.
If not set, the command line will request the password when it is required. - Set either
--notimestamp
if the signature should be CAdES-B, or--timestamp
for CAdES-T.
If you want to sign with CAdES-T, additionally a timestamp configuration file is necessary and the--timestampconfiguration <path to timestampconfiguration file>
parameter need to be set.
...by means of Visual Studio®
- To configure the signing of a library in Visual Studio®, right click on your project in the Solution Explorer, select PLCnext Technology → Project Configuration.
- Switch to the Signing tab and make your choices:
- Signing can be generally activated or deactivated.
- Then there are two options, how the necessary files can be provided:
- The first option is a PKCS#12 Container, this contains a public and a private key to sign and a (derived) certificate of the issuing certificate authority.
- The second option is to provide these files in the PEM format file by file.
- Both the container and the private key can be password protected. The password can be stored for the user per project and is protected by the default Visual Studio® mechanism.
- Another option is to add a timestamp configuration file for a CAdES-T signature.
...by means of Eclipse®
- To configure the signing of a library in Eclipse®, open the project properties, select PLCnext Technology → PLCnext Signing.
- Make your choices:
- Signing can be generally activated or deactivated.
- Then there are two options, how the necessary files can be provided:
- The first option is a PKCS#12 Container, this contains a public and a private key to sign and a (derived) certificate of the issuing certificate authority.
- The second option is to provide these files in the PEM format file by file.
- Both the container and the private key can be password protected. The password can be stored for the user per project and is protected by the default Eclipse® mechanism.
- Another option is to add a timestamp configuration file for a CAdES-T signature.
Reference
Certificate configuration for signing and verifying
To ensure proper validation of CA certificates and entity certificates, follow these guidelines:
CA Certificate Validation
- Certificate Version:
- Ensure the certificate is X.509 version 3.
- Key Usage: The certificate must have the following key usages:
- keyCertSign (Value 5): Allows the key to sign other certificates.
- cRLSign (Value 6): Allows the key to sign certificate revocation lists (CRLs).
- Critical Key Usage: -Ensure the Key Usage extension is marked as critical.
- Extended Key Usage Presence: If the certificate has the Extended Key Usage extension, validate against expected key purposes such as:
- AnyExtendedKeyUsage (optional)
- id_kp_serverAuth (optional)
- id_kp_emailProtection (optional)
- Depending on the usage of the certificate, check:
- id_kp_codeSigning (mandatory) or
- id_kp_timeStamping (mandatory)
Entity Certificate Validation
- Certificate Version: Ensure the certificate is X.509 version 3.
- Key Usage:
- The certificate must have the key usage digitalSignature (Value 0); this allows the key to create digital signatures.
- The certificate must not have the key usage keyCertSign (Value 5) or cRLSign (Value 6).
- Critical Key Usage: Ensure the key usage extension is marked as critical.
- Extended Key Usage: Validate against expected key purposes, such as:
- AnyExtendedKeyUsage (optional)
- id_kp_serverAuth (optional)
- depending on the usage of the certificate, check:
- id_kp_codeSigning (mandatory) or
- id_kp_timeStamping (mandatory)
Glossary & abbreviations for this topic
- Signature Types:
- CAdES-B: Basic signature that ensures the integrity and authenticity of the signed data. It does not include a timestamp.
- CAdES-T: Timestamped signature that includes a timestamp from a trusted timestamp authority, providing proof that the signature existed at a specific time.
- Conformance: Defines the verification process based on signature type and timestamp. It includes:
- Signed: Conformance check using the current UTC DateTime (CAdES-B signature Type).
- SignedWithTimestamp: Conformance check using the provided timestamp (CAdES-T signature Type).
- Automatic: The system decides whether to use the provided timestamp's (if available), or defaults to the current UTC
DateTime
.
- Digest Algorithm: Cryptographic hash functions. Supported algorithms are:
- SHA256
- SHA384
- SHA512
- Signature Algorithm: Digital signature methods. Supported algorithms are:
- RSA
- RSAPSS: an RSA variant with a probabilistic signature scheme
- ECDSA: using elliptic curve cryptography
CAdES-T: Timestamp Configuration File
The timestamp configuration file is needed, if the signature should be of type CAdES-T.
- All information necessary for accessing a time server must be put in this configuration file.
- The
TimeStampServerCredentials
are optional. - The
Proxy
is optional, and – if not configured – the system defaults are used.
Example:
{
"TimestampServer": "http://test.com",
"TimeStampServerCredentials": {
"UserName": "userName",
"Password": "pwd",
"Domain": "domain"
},
"Proxy": {
"Address": "http://test.com:8080",
"BypassOnLocal": true,
"BypassList": [
"bypass1",
"bypass2"
],
"Host": "test.com",
"Port": 8080,
"IsDefault": false,
"ProxyCredentials": {
"UserName": "proxyUserName",
"Password": "proxyPwd",
"Domain": "proxyDomain"
}
},
"DigestAlgorithm": "SHA256",
"SignatureAlgorithm": "Rsa"
}