Each item in this list specifies a cipher that the TLS client is allowed to use.
When {{empty}} the system defaults are used.
Each item in this list specifies a cipher that the TLS server is allowed to use.
When {{empty}} the system defaults are used.
Specifies the client certificate that must be presented to the remote server for mutual authentication.
This certificate is used to authenticate the client by the remote server, ensuring that the remote server is communicating with a trusted client.
The client certificate must be issued by a trusted Certificate Authority (CA) and should match the client's private key.
This parameter is applicable only when a TLS session is being used.
Specifies the group of CA certificate(s) that the client must use to validate the certificate presented by the remote server.
These CA certificates form a trust chain that the server certificate must match, ensuring that only servers with trusted certificates can establish a connection.
This parameter supports multiple CA certificates to accommodate different server certificate issuers.
This parameter is applicable only when a TLS session is being used.
Specifies the server certificate to be presented by the server during the TLS handshake.
This certificate is used to authenticate the server to remote clients, ensuring that the clients are connecting to a legitimate server.
The server certificate must be issued by a trusted Certificate Authority (CA) and should match the server's private key.
This parameter is applicable only when a TLS session is being used.
Specifies the group of CA certificate(s) that the server must use to validate the certificate presented by the remote client.
These CA certificates form a trust chain that the client certificate must match, ensuring that only clients with trusted certificates can establish a connection.
This parameter supports multiple CA certificates to accommodate different client certificate issuers.
This parameter is applicable only when a TLS session is being used.
This object contains general information related to managing security
features on the device.
{{numentries}}
{{numentries}}
This table provides information about all types of public key-based
credentials, such as X.509 certificates, see {{bibref|RFC5280}}.
Enables or disables this certificate.
User-defined name to identify and categorize the certificate (e.g.,
"mqtt-broker", "webserver", "vpn-client"). The implementation MAY
use this name to determine which secure storage to use and how to
persist the key.
The last modification time of this certificate.
The Serial Number field in an X.509 certificate, see
{{bibref|RFC5280}}.
The Issuer field in an X.509 certificate, see {{bibref|RFC5280}};
i.e. the Distinguished Name (DN) of the entity who has signed the
certificate.
The beginning of the certificate validity period; i.e. the Not Before
field in an X.509 certificate, see {{bibref|RFC5280}}.
The end of the certificate validity period; i.e., the Not After field
in an X.509 certificate, see {{bibref|RFC5280}}.
The Distinguished Name (DN) of the entity associated with the Public
Key; i.e., the Subject field in an X.509 certificate, see
{{bibref|RFC5280}}.
{{list}} Each item specifies an identity that is bound to the
certificate's subject, and thus bound to the Public Key.
The Subject Alternative Names extension field in an X.509 certificate,
see {{bibref|RFC5280}}.
The algorithm used in signing the certificate; i.e. the Signature
Algorithm field in an X.509 certificate, see {{bibref|RFC5280}}.
This table stores information about a group of Certificate Authorities (CAs).
A CA is a trusted entity that issues digital certificates used to verify the identity of servers,
clients, or other entities in secure communication protocols like TLS.
This group defines a collection of trusted CA certificates that can be used to validate server certificates during TLS connections.
Enables or disables this CA group.
When disabled, the certificates within this group will not be used for validation.
The textual name assigned to this CA group for identification.
Specifies the CA certificate(s) that the client must use to validate the certificate presented by the remote server.
These CA certificates form a trust chain that the server certificate must match, ensuring that only servers with trusted certificates can establish a connection.
This parameter supports multiple CA certificates to accommodate different server certificate issuers.
This parameter is applicable only when a TLS session is being used.
Returns the path to the X.509 certificate and its corresponding private key that is
associated with the entry of the {{object}} table.
The absolute or relative path to the certificate file,
specified as an {{bibref|RFC8089}} (The file URI Scheme).
The URI for the private key associated with this certificate, formatted according to
{{bibref|RFC7512}}. This URI should point to the key's location on a hardware security
module (HSM) or other cryptographic token.
For security reasons, the URI MUST NOT include any PIN information (e.g.,`pin-value`). The
service responsible for managing the token should inject the required PIN at runtime. This
practice prevents unauthorized access and malicious reuse of the private key by other
services.
Deletes the certificate.
Returns the path to the directory containing CA certificates.
This is necessary for services, especially microservices in host or
container environments requiring mTLS, to locate the appropriate
CA certificates during configuration.
Depending on the security requirements a service-specific CA directory
may be required.
This parameter specifies the absolute or relative path to the
directory containing the CA certificate bundle,
specified as an {{bibref|RFC8089}} URI (The file URI Scheme).
Returns the path to a file containing one or more CA certificates.
This is necessary for services, especially microservices in host or
container environments requiring mTLS, to locate the appropriate
CA certificates during configuration.
Depending on the security requirements a service-specific CA file
may be required.
The absolute or relative path to the file containing the
CA certificate(s), specified as an {{bibref|RFC8089}} URI (The file URI Scheme).
Updates the CA bundle with new certificate content. The new
bundle completely replaces the existing CA certificates.
For example, if the current bundle contains 5 CA
certificates and the new bundle contains only 3 CA
certificates, the 2 CA certificates that are not present in
the new bundle will be deleted.
If the update fails, the previous bundle is kept as-is.
The device SHOULD reject the operation with the following
fault codes for specific error conditions:
* If the bundle does not contain valid PEM formatted
certificates, the device SHOULD reject the operation with a
7265 (Invalid PEM Format) fault code.
* If the bundle could not be imported, the device SHOULD
reject the operation with a 7262 (Failed To Import Bundle)
fault code.
* If one or more certificates in the bundle could not be
imported, the device SHOULD reject the operation with a 7263
(Failed To Import Certificate) fault code.
* If there is insufficient disk space to store the CA bundle,
the device SHOULD reject the operation with a 7266
(Insufficient Disk Space) fault code.
One or more X.509 CA certificates in PEM format,
concatenated into a single PEM file.
The number of CA certificates successfully installed
from the bundle.
Deletes the CA bundle.
Each item indicates a bundle format that is supported by the
{{command|AddCertificateBundle()}} command.
The device installs the new bundle and updates the
`Device.Security.Certificate.{i}`. The bundle (e.g., PKCS#12,
PEM) contains both a certificate and a private key.
If a certificate with the same
{{param|Device.Security.Certificate.{i}.SerialNumber}} and
{{param|Device.Security.Certificate.{i}.Issuer}} already
exists in the device, the existing certificate is replaced
with the new certificate, and the {{param|Certificate}}
output parameter references the updated entry.
The device SHOULD reject the operation with the following
fault codes for specific error conditions:
* If the specified bundle format is not supported, the device
SHOULD reject the operation with a 7260 (Bundle Format Not
Supported) fault code.
* If the bundle signature verification fails, the device
SHOULD reject the operation with a 7261 (Bundle Signature
Failure) fault code.
* If the bundle could not be imported, the device SHOULD
reject the operation with a 7262 (Failed To Import Bundle)
fault code.
* If the certificate in the bundle could not be imported, the
device SHOULD reject the operation with a 7263 (Failed To
Import Certificate) fault code.
* If the private key in the bundle could not be imported, the
device SHOULD reject the operation with a 7264 (Failed To
Import Private Key) fault code.
* If the certificate has a SerialNumber and Issuer that match an
existing certificate with a different Name, the device SHOULD
reject the operation with a 7270 (Certificate Identity Conflict)
fault code.
An optional input the Controller can use to specify the
{{param|.Security.Certificate.{i}.Alias}} value for the added entry.
If provided as an input and the value already exists in
{{object|.Security.Certificate.{i}}}, this command will fail.
User-defined name to identify the certificate.
If a certificate with the same Name already exists in
{{object|.Security.Certificate.{i}.}}, the existing certificate will be
replaced with the certificate from the bundle.
The format of the bundle.
The bundle containing the certificate and private key.
It is good practice for the bundle to be encrypted and
signed.
How the bundle is decrypted, verified, and installed on
the system depends on the device design and is
considered implementation specific.
Specifies the location where the certificate was
installed.
The device installs the new CA bundle and adds an entry to
the {{object|Device.Security.CABundle.{i}.}} table.
If a CA bundle with the same
{{param|Device.Security.CABundle.{i}.Name}} already exists
in the device, the device SHOULD reject the operation with a
7267 (Duplicate CA Bundle Name) fault code.
The device SHOULD reject the operation with the following
fault codes for specific error conditions:
* If the bundle does not contain valid PEM formatted
certificates, the device SHOULD reject the operation with a
7265 (Invalid PEM Format) fault code.
* If the bundle could not be imported, the device SHOULD
reject the operation with a 7262 (Failed To Import Bundle)
fault code.
* If one or more certificates in the bundle could not be
imported, the device SHOULD reject the operation with a 7263
(Failed To Import Certificate) fault code.
* If there is insufficient disk space to store the CA bundle,
the device SHOULD reject the operation with a 7266
(Insufficient Disk Space) fault code.
The name of the new CA bundle.
One or more X.509 CA certificates in PEM format,
concatenated into a single PEM file.
Specifies the location where the CA bundle was installed.
The number of CA certificates successfully installed
from the bundle.