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.
If neither a {{param}} nor {{param|CABundle}} is provided to this command and an entry exists in {{object|Device.Security.ClientCertificateDefault.{i}}}
with {{param|Device.Security.ClientCertificateDefault.{i}.Type}} matching this command, then the Certificate and CABundle values will be used from
{{object|Device.Security.ClientCertificateDefault.}}.
If neither a {{param|Certificate}} nor {{param}} is provided to this command and an entry exists in {{object|Device.Security.ClientCertificateDefault.{i}}}
with {{param|Device.Security.ClientCertificateDefault.{i}.Type}} matching this command, then the Certificate and CABundle values will be used from
{{object|Device.Security.ClientCertificateDefault.}}.
The {{datatype}} specifying the destination file location. The
HTTPS transport MUST be supported, and the HTTP transport MAY be
supported.
The PUT request method MUST be used to transfer the file.
This argument specifies only the destination file location, and
does not indicate in any way the name or location of the local
file to be uploaded.
If the Agent receives multiple upload requests with the same URL,
the Agent MUST perform each upload as requested, and MUST NOT
assume that the content of the file to be uploaded is the same
each time.
This URL MUST NOT include the "userinfo" component, as defined in
{{bibref|RFC3986}}.
Username to be used by the Agent to authenticate with the file
server. If {{param}} is not provided or is set to {{empty}}, an alternative form of
authentication (e.g., certificate-based authentication) is required.
Note: The mandatory requirement for this parameter was removed in Device:2.20.
Password to be used by the Agent to authenticate with the file
server. If {{param}} is not provided or is set to {{empty}}, an alternative form of
authentication (e.g., certificate-based authentication) is required.
Note: The mandatory requirement for this parameter was removed in Device:2.20.
The {{datatype}} specifying the source file location. The HTTPS
transport MUST be supported, and the HTTP transport MAY be
supported.
If the Agent receives multiple download requests with the same
source URL, the Agent MUST perform each download as requested,
and MUST NOT assume that the content of the file to be downloaded
is the same each time.
This URL MUST NOT include the "userinfo" component, as defined in
{{bibref|RFC3986}}.
Username to be used by the Agent to authenticate with the file
server. If {{param}} is not provided or is set to {{empty}},
either an alternative form of authentication (e.g.,
certificate-based authentication) is required or no
authentication is required.
Password to be used by the Agent to authenticate with the file
server. If {{param}} is not provided or is set to {{empty}},
either an alternative form of authentication (e.g.,
certificate-based authentication) is required or no
authentication is required.
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}}
{{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}}.
Specifies the automatic certificate update mode. When auto-update
is triggered, certificate information is copied from {{object}}
to populate the new CSR.
Auto-update is disabled.
When auto-update is triggered, the device creates a new
CSR. If an existing key pair is available for this
certificate, it is reused (certificate renewal as defined
in {{bibref|RFC3647|Section 4.4.6}}). Otherwise, a new
key pair is generated.
When auto-update is triggered, the device always generates
a new key pair and creates a new CSR, regardless of
whether an existing private key is available (certificate
re-key as defined in {{bibref|RFC3647|Section 4.4.6}}).
The existing private key is replaced once the new
certificate is installed.
Number of {{units}} before {{param|NotAfter}} at which the
device automatically initiates a new CSR, as determined by
{{param|RenewalMode}}. A value of 0, or
{{enum|None|RenewalMode}} for {{param|RenewalMode}},
disables auto-update.
If {{param}} is greater than or equal to the certificate
validity period (the interval between {{param|NotBefore}} and
{{param|NotAfter}}), or if the computed trigger date
({{param|NotAfter}} minus {{param}} {{units}}) already lies in
the past, the device SHOULD initiate auto-update immediately.
See {{bibref|RFC5280|Section 4.1.2.5}} for the certificate
validity period definition.
{{true}} when the device has the private key for this certificate.
{{false}} when the device does not have the private key (e.g.,
imported CA certificate for trust chain validation).
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.
This table provides a default Certificate and CABundle for commands that are invoked without explicitly specifying them as a parameter.
Specifies the command this entry applies to.
Default applies to FirmwareImage Download command
Default applies to KernelFault Upload command
Default applies to ProcessFault Upload command
Default applies to VendorConfigFile Backup command
Default applies to VendorConfigFile Restore command
Default applies to VendorLogFile Upload command
{{numentries}}
This table lists the Certificate Signing Requests (CSRs) created by
the device, either automatically to auto-update an existing certificate
or in response to a {{command|.Security.CreateCSR()}}. When a
certificate is installed whose public key matches that of a CSR, the
CSR is automatically deleted.
If no certificate is installed before the timeout defined by
{{param|.Security.CSRTimeout}} expires, the CSR entry is
automatically deleted. Its associated private key is also deleted,
unless it is already referenced by an existing
{{object|#.Certificate}} entry (e.g., in
{{enum|Renew|RenewalMode}} mode).
If a pending entry with the same {{param|Name}} already exists when
{{command|.Security.CreateCSR()}} is invoked, the device SHOULD
reject the new operation with a 7005 (Resources Exceeded) fault
code. The Controller MAY cancel the pending request via
{{command|.LocalAgent.Request.{i}.Cancel()}}, which causes the device
to remove the CSR entry and its associated private key (unless
referenced by an existing {{object|#.Certificate}} entry), before
retrying.
The CSR in PEM format (PKCS#10, signed by the device,
Base64 encoded with header and footer).
Date and time the CSR was created.
User-defined name to identify the certificate, as specified in the
{{command|.Security.CreateCSR()}} command that generated this CSR.
This name is associated with the certificate when it is added
via {{command|.Security.AddCertificate()}}.
The Basic Constraints extension specified when creating the CSR, as
defined in {{bibref|RFC5280|Section 4.2.1.9}}.
When {{true}}, the certificate is a CA certificate (CA:TRUE).
When {{false}}, the certificate is an end-entity certificate (CA:FALSE).
The path length constraint specified when creating the CSR, as defined in
{{bibref|RFC5280|Section 4.2.1.9}}.
Specifies the maximum number of non-self-issued intermediate certificates that may
follow this certificate in a valid certification path. A value of zero means this
certificate may be directly followed only by end-entity certificates. Where no path
length constraint was specified, no upper limit is imposed.
This parameter is meaningful only when {{param|BasicConstraints}} is {{true}} and
{{enum|KeyCertSign|KeyUsageList}} is present in {{param|KeyUsageList}}.
The value -1 indicates that no path length constraint was specified in the CSR,
or that {{param|BasicConstraints}} is {{false}}.
Each item specifies a Key Usage purpose specified when creating the
CSR, as defined in {{bibref|RFC5280|Section 4.2.1.3}}.
Digital signature.
Non-repudiation.
Key encipherment.
Data encipherment.
Key agreement.
Certificate signing.
CRL signing.
Encipher only.
Decipher only.
Each item specifies an Extended Key Usage (EKU) purpose for the
certificate, as defined in {{bibref|RFC5280|Section 4.2.1.12}}. The
EKU extension indicates the purposes for which the certificate public
key may be used.
TLS server authentication.
TLS client authentication.
Code signing.
Email protection (S/MIME).
Timestamping.
OCSP response signing.
The automatic certificate update mode requested when this CSR was
created.
Auto-update is disabled.
When auto-update is triggered, the device creates a new
CSR. If an existing key pair is available for this
certificate, it is reused (certificate renewal as defined
in {{bibref|RFC3647|Section 4.4.6}}). Otherwise, a new
key pair is generated.
When auto-update is triggered, the device always generates
a new key pair and creates a new CSR, regardless of
whether an existing private key is available (certificate
re-key as defined in {{bibref|RFC3647|Section 4.4.6}}).
The existing private key is replaced once the new
certificate is installed.
Number of {{units}} before the NotAfter date at which the
device automatically initiates a new CSR, as determined by
{{param|RenewalMode}}. A value of 0, or
{{enum|None|RenewalMode}} for {{param|RenewalMode}},
disables auto-update.
If {{param}} is greater than or equal to the certificate
validity period (see {{bibref|RFC5280|Section 4.1.2.5}}), or
if the computed trigger date already lies in the past, the
device SHOULD initiate auto-update immediately.
The ''command_key'' supplied in the
{{command|.Security.CreateCSR()}} Operate message that generated
this CSR. This value can be used to correlate this CSR entry with
the resulting {{event|#.CSRCreated!}} or {{event|#.CSRFailure!}}
event, and eventually the certificate added via
{{command|.Security.AddCertificate()}}. This will be {{empty}} if
the CSR was automatically created due to certificate auto-update
rather than an explicit controller request.
When auto-update is triggered, a {{event|#.CSRCreated!}} event is
generated upon successful creation of the new CSR, or a
{{event|#.CSRFailure!}} event if the attempt fails.
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.
This table provides a default Certificate and CABundle for commands such as {{command|Device.DeviceInfo.FirmwareImage.{i}.Download()}} when called without an explicit Certificate or CABundle as a parameter.
Specifies the command this entry applies to.
Default applies to {{command|Device.DeviceInfo.FirmwareImage.{i}.Download()}}
Default applies to {{command|Device.DeviceInfo.KernelFaults.KernelFault.{i}.Upload()}}
Default applies to {{command|Device.DeviceInfo.ProcessFaults.ProcessFault.{i}.Upload()}}
Default applies to {{command|Device.DeviceInfo.VendorConfigFile.{i}.Backup()}}
Default applies to {{command|Device.DeviceInfo.VendorConfigFile.{i}.Restore()}}
Default applies to {{command|Device.DeviceInfo.VendorLogFile.{i}.Upload()}}
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.
An optional input the Controller can use to specify the
{{param|.Security.CABundle.{i}.Alias}} value for the added entry.
If provided as an input and the value already exists in
{{object|.Security.CABundle.{i}}}, this command will fail.
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.
The number of {{units}} a pending
{{object|.Security.CSR.{i}.}} entry is retained before being
automatically deleted. Its associated private key is also
deleted, unless it is already referenced by an existing
{{object|.Security.Certificate.{i}.}} entry (e.g., in
{{enum|Renew|.Security.CSR.{i}.RenewalMode}} mode).
A CSR entry is considered pending until a matching certificate
is installed via {{command|.Security.AddCertificate()}}. This
timeout applies to all CSR entries, regardless of whether they
were created explicitly via {{command|.Security.CreateCSR()}}
or automatically during an auto-update cycle.
A value of 0 disables automatic expiry.
This command causes the device to generate a CSR using a
locally-created and secure private key.
{{param|RenewalMode}} determines whether an existing key
pair is reused ({{enum|Renew|RenewalMode}}) or a new one
is always generated ({{enum|ReKey|RenewalMode}}), both for
the current invocation and for future auto-update cycles.
{{param|RenewalInterval}} controls when the auto-update is
triggered relative to the certificate expiry date.
If a pending {{object|.Security.CSR.{i}.}} entry with the same
{{param|Name}} already exists, the device SHOULD reject the
operation with a 7005 (Resources Exceeded) fault code. The
Controller MAY cancel the pending request via
{{command|.LocalAgent.Request.{i}.Cancel()}}, which causes the
device to remove the CSR entry and its associated private key
(unless referenced by an existing
{{object|.Security.Certificate.{i}.}} entry), before
retrying.
If a {{object|.Security.Certificate.{i}.}} entry with the same
{{param|Name}} already exists, it remains in place until the new
certificate is installed via {{command|AddCertificate()}}.
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.
Identifier for the type of asymmetric key pair the device is to
create for the CSR. Common examples include RSA (see
{{bibref|RFC8017}}), ECDSA with P-256, ECDSA with P-384, Ed25519,
and Ed448.
The length of the key to be created, in {{units}}. Only applicable when
{{param|KeyType}} specifies RSA; for RSA, common values are 2048 and
4096 {{units}}. For other key types (e.g., ECDSA, Ed25519, Ed448), the
key length is fixed by the algorithm and this parameter is ignored.
The Basic Constraints extension specified when creating the CSR, as
defined in {{bibref|RFC5280|Section 4.2.1.9}}.
When {{true}}, the certificate is a CA certificate (CA:TRUE).
When {{false}}, the certificate is an end-entity certificate (CA:FALSE).
The path length constraint to request in the CSR, as defined in
{{bibref|RFC5280|Section 4.2.1.9}}.
Only applicable when {{param|BasicConstraints}} is {{true}}. Specifies the
maximum number of non-self-issued intermediate certificates that may follow
this certificate in a valid certification path. A value of zero means this
certificate may be directly followed only by end-entity certificates.
The value -1 indicates that no path length constraint is requested.
Each item specifies a Key Usage purpose for the certificate, as
defined in {{bibref|RFC5280|Section 4.2.1.3}}. The Key Usage
extension defines the cryptographic operations for which the
certificate public key may be used. This parameter is optional in
the CSR, and the CA may apply its own policy when issuing the
certificate.
Digital signature (verify signatures on data other than
certificates and CRLs).
Non-repudiation (content commitment).
Key encipherment (encrypt keys for transport).
Data encipherment (encrypt user data).
Key agreement (e.g., Diffie-Hellman).
Certificate signing (sign certificates). Typically used for
CA certificates.
CRL signing (sign certificate revocation lists). Typically
used for CA certificates.
Encipher only (used with KeyAgreement).
Decipher only (used with KeyAgreement).
Each item specifies an Extended Key Usage (EKU) purpose for the
certificate, as defined in {{bibref|RFC5280|Section 4.2.1.12}}.
The EKU extension indicates the purposes for which the
certificate public key may be used. This parameter is optional in
the CSR, and the CA may apply its own policy when issuing the
certificate.
TLS server authentication.
TLS client authentication.
Code signing.
Email protection (S/MIME).
Timestamping.
OCSP response signing.
Subject Alternative Name entries to include in the CSR. The SAN
extension allows additional identities to be bound to the
certificate subject, such as DNS names, IP addresses, URIs, or
email addresses. Modern certificates often rely primarily on SAN
rather than the CN field. At least one of
{{param}} or {{param|CommonName}} must be
specified to identify the certificate subject. See
{{bibref|RFC5280|Section 4.2.1.6}} for the Subject Alternative
Name extension.
Common Name to include in the CSR. This maps to the CN attribute
in the Subject field of the certificate's Distinguished Name. The
CN typically identifies the entity to which the certificate is
issued, such as a hostname or service name. At least one of
{{param}} or {{param|SubjectAlternativeName}} must be
specified to identify the certificate subject. See
{{bibref|RFC5280|Section 4.1.2.4}} for DN attribute type
definitions and {{bibref|RFC5280|Section 4.1.2.6}} for usage in
the Subject field.
Organization Name to include in the CSR. This maps to the O
attribute in the Subject field of the certificate's Distinguished
Name. The O attribute identifies the organization to which the
certificate subject belongs. See
{{bibref|RFC5280|Section 4.1.2.4}} for DN attribute type
definitions and {{bibref|RFC5280|Section 4.1.2.6}} for usage in
the Subject field.
Organizational Unit to include in the CSR. This maps to the OU
attribute in the Subject field of the certificate's Distinguished
Name. The OU attribute identifies a subdivision or department
within the organization. See
{{bibref|RFC5280|Section 4.1.2.4}} for DN attribute type
definitions and {{bibref|RFC5280|Section 4.1.2.6}} for usage in
the Subject field.
Locality to include in the CSR. This maps to the L attribute in
the Subject field of the certificate's Distinguished Name. The L
attribute identifies the city, town, or village where the
organization is located. See
{{bibref|RFC5280|Section 4.1.2.4}} for DN attribute type
definitions and {{bibref|RFC5280|Section 4.1.2.6}} for usage in
the Subject field.
State or province name to include in the CSR. This maps to the ST
attribute in the Subject field of the certificate's Distinguished
Name. The ST attribute identifies the state or province where the
organization is located. See
{{bibref|RFC5280|Section 4.1.2.4}} for DN attribute type
definitions and {{bibref|RFC5280|Section 4.1.2.6}} for usage in
the Subject field.
Country name to include in the CSR. This maps to the C attribute
in the Subject field of the certificate's Distinguished Name. The
C attribute is a two-letter country code as defined in
{{bibref|ISO3166-1}}. See {{bibref|RFC5280|Section 4.1.2.4}} for
DN attribute type definitions and
{{bibref|RFC5280|Section 4.1.2.6}} for usage in the Subject
field.
Email address to include in the CSR. This maps to the Email
attribute in the Subject field of the certificate's Distinguished
Name. The EMAIL attribute provides a contact email address for
the certificate subject. See
{{bibref|RFC5280|Section 4.1.2.4}} for DN attribute type
definitions and {{bibref|RFC5280|Section 4.1.2.6}} for usage in
the Subject field.
The automatic certificate update mode to apply once the
certificate is installed.
Auto-update is disabled.
When auto-update is triggered, the device creates a
new CSR. If an existing key pair is available for
this certificate, it is reused (certificate renewal
as defined in {{bibref|RFC3647|Section 4.4.6}}).
Otherwise, a new key pair is generated.
When auto-update is triggered, the device always
generates a new key pair and creates a new CSR,
regardless of whether an existing private key is
available (certificate re-key as defined in
{{bibref|RFC3647|Section 4.4.6}}). The existing
private key is replaced once the new certificate
is installed.
Number of {{units}} before the certificate expires at
which the device automatically initiates a new CSR, as
determined by {{param|RenewalMode}}. A value of 0
disables auto-update.
If {{param}} is greater than or equal to the certificate
validity period, or if the computed trigger date already
lies in the past, the device SHOULD initiate auto-update
immediately.
The CSR in PEM format (PKCS#10, signed by the device,
Base64 encoded with header and footer). Returned upon
successful completion of the command.
This command is issued to add a new certificate to
{{object|.Security.Certificate.{i}.}}. The certificate, provided in PEM format, is
parsed to populate the parameters of the Certificate table. If
{{param|MatchToCSR}} is {{true}}, the private key that was used to
sign the matching CSR is associated with the certificate and the CSR
is deleted.
If a certificate with the same {{param|Name}} already exists, the existing certificate
entry is replaced with the new certificate. This replacement involves:
* The old certificate and its associated private key are securely deleted
* The new certificate is added with the new private key (from the matching CSR)
* The {{param|Name}} is assigned to the new certificate entry
The device SHOULD reject the operation with the following
fault codes for specific error conditions:
* If {{param|MatchToCSR}} is {{true}} and no matching CSR was
found for the certificate, the device SHOULD reject the
operation with a 7268 (No Matching CSR) fault code.
* If the certificate could not be imported, the device SHOULD
reject the operation with a 7263 (Failed To Import Certificate)
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.
When {{param|MatchToCSR}} is {{true}}, the name from the matching
CSR is used instead.
When {{param|MatchToCSR}} is {{false}}, this parameter MUST be
specified.
If a certificate with the same name already exists, it will be
replaced.
The X.509 certificate in PEM {{bibref|RFC7468}} format.
{{true}} if the certificate being added is in response to a CSR
sent by the device, otherwise {{false}}. If {{true}}, info from
the matching CSR, including private key and name, is associated with the
certificate and the CSR deleted. If {{true}} and no matching CSR
is found, the device SHOULD reject the operation with a 7268
(No Matching CSR) fault code.
The automatic certificate update mode to apply to the
resulting {{object|.Security.Certificate.{i}.}} entry.
Number of {{units}} before the certificate expires at
which the device automatically initiates a new CSR, as
determined by {{param|RenewalMode}}. A value of 0
disables auto-update.
This event notifies a USP Controller that the device has created a new CSR.
The ''command_key'' supplied in the
{{command|.Security.CreateCSR()}} Operate message that generated
this CSR. This value correlates the event with the original
command invocation and the CSR entry in
{{object|.Security.CSR.{i}.}}. This will be {{empty}} if the
CSR was automatically created due to certificate auto-update.
User-defined name to identify the certificate, as specified in the
{{command|.Security.CreateCSR()}} command that generated this CSR.
This name is associated with the certificate when it is added
via {{command|.Security.AddCertificate()}}.
The CSR in PEM format (PKCS#10, signed by the device,
Base64 encoded with header and footer).
This event notifies a USP Controller that the device has tried but failed
to create a new CSR.
The ''command_key'' supplied in the
{{command|.Security.CreateCSR()}} Operate message that failed.
This value correlates the event with the original command
invocation. This will be {{empty}} if the failure occurred
during an automatic certificate auto-update attempt.
User-defined name to identify the certificate, as specified in the
{{command|.Security.CreateCSR()}} command that generated this CSR.
This name is associated with the certificate when it is added
via {{command|.Security.AddCertificate()}}.
A non-zero USP fault code indicating the reason the CSR
creation failed. If the failure occurred during an
auto-update cycle and no {{command|.Security.CreateCSR()}}
Operate message was involved, this reflects the internal
error condition.
A human-readable description of the fault. SHOULD be
{{empty}} if {{param|FaultCode}} is 0.