Certificates are digitally signed data structures that contain a Public Key and the identity of a OPC UA Application. All SecurityProtocols use X.509 v3 Certificates (see X.509 v3) encoded using the DER format (see X690). Certificates used by OPC UA applications shall also conform to RFC 5280 which defines a profile for X.509 v3 Certificates when they are used as part of an Internet based application.
The ServerCertificate and ClientCertificate parameters used in the abstract OpenSecureChannel service are instances of the ApplicationInstance Certificate DataType. Clause 6.2.2 describes how to create an X.509 v3 Certificate that can be used as an ApplicationInstance Certificate.
Certificates are also used as form of UserIdentityToken which identifies a user associated with a Session. Clause 6.2.3 describes Certificates used as UserIdentityTokens.
An Application Instance Certificate is a ByteString containing the DER encoded form (see X690) of an X.509 v3 Certificate. This Certificate is issued by certifying authority and identifies an instance of an application running on a single host. The X.509 v3 fields contained in an Application Instance Certificate are described in Table 46. The fields are defined completely in RFC 5280.
Table 46 also provides a mapping from the RFC 5280 terms to the terms used in the abstract definition of an Application Instance Certificate defined in OPC 10000-4.
Table 46 – Application Instance Certificate
|
Name |
OPC 10000-4 Parameter Name |
Description |
|
Application Instance Certificate |
|
An X.509 v3 Certificate. |
|
version |
version |
shall be “V3” |
|
serialNumber |
serialNumber |
The serial number assigned by the issuer. |
|
signatureAlgorithm |
signatureAlgorithm |
The algorithm used to sign the Certificate. |
|
signature |
signature |
The signature created by the Issuer. |
|
issuer |
issuer |
The distinguished name of the Certificate used to create the signature. |
|
validity |
validTo, validFrom |
When the Certificate becomes valid and when it expires. |
|
subject |
subject |
The distinguished name of the application Instance. The Common Name attribute shall be specified and should be the productName or a suitable equivalent. The Organization Name attribute shall be the name of the Organization that executes the application instance. This organization is usually not the vendor of the application. Other attributes may be specified. |
|
subjectAltName |
applicationUri, hostnames |
The alternate names for the application Instance. Shall include a uniformResourceIdentifier which is equal to the applicationUri. The URI shall be a valid URL (see RFC 3986) or a valid URN (see RFC 8141). Servers shall specify a partial or a fully qualified dNSName or a static IPAddress which identifies the machine where the application Instance runs. Additional dNSNames may be specified if the machine has multiple names. The subjectAltName field is completely described in RFC 5280. |
|
publicKey |
publicKey |
The public key associated with the Certificate. |
|
keyUsage |
keyUsage |
Specifies how the Certificate key may be used. For RSA keys, the keyUsage shall include digitalSignature, nonRepudiation, keyEncipherment and dataEncipherment.For ECC keys, the keyUsage shall include digitalSignature.Other keyUsage bits are allowed but not recommended. Self-signed Certificates shall also include keyCertSign. |
|
extendedKeyUsage |
keyUsage |
Specifies additional limits on how the Certificate key may be used. For RSA profiles, the extendedKeyUsage shall specify serverAuth for Servers and shall specify clientAuth for Clients. The extendedKeyUsage should also specify clientAuth for Servers. For ECC profiles, serverAuth and clientAuth are optional. Other extendedKeyUsage bits are allowed. |
|
authorityKeyIdentifier |
(No mapping) |
Provides more information about the key used to sign the Certificate. It shall be specified for Certificates signed by a CA. It should be specified for self-signed Certificates. |
|
basicConstraints |
(No mapping) |
The basicConstraints field is completely described in RFC 5280. The cA flag Identifies whether the subject of the Certificate is a CA The pathLength specifies the maximum number of intermediate CAs in valid chains that follow this Certificate.
The basicConstraints extension shall be present and shall not be ignored. The extension shall be validated and marking the extension as critical has no effect. For backward interoperability, any error related to the critical mark produced by software libraries shall be suppressed and logged as a warning.
The cA flag shall be FALSE for any ApplicationInstance Certificate, however, TRUE shall be accepted to ensure backward interoperability when validating ApplicationInstance Certificates, if revocation checks are enabled. If revocation checks are disabled then a Certificate with the cA flag set to TRUE should not be accepted. It should be possible to disable backward interoperability in configuration.
If the cA flag is TRUE for a self-signed ApplicationInstance Certificate, then the pathLength should be 0. If an application accepts an ApplicationInstance Certificate with cA flag set to TRUE, it shall write a warning to the log. |
A User Certificate is a Certificate is issued by certifying authority and identifies a user.
The X.509 v3 fields in a User Certificates with specific requirements are shown in Table 47.
|
Field |
Description |
|
subject |
The distinguished name of the User. The Common Name attribute shall be specified and should be name of the user. The Organization should be provided. Other attributes may be specified. |
|
authorityKeyIdentifier |
Provides more information about the key used to sign the Certificate. It shall be specified. |
|
basicConstraints |
The basicConstraints field is completely described in RFC 5280. The cA flag Identifies whether the subject of the Certificate is a CA The pathLength specifies the maximum depth of valid chains that include this Certificate. The cA flag shall be FALSE for User Certificates. The pathLength shall not be present. |
An Issuer or CA Certificate is an X.509 v3 Certificate that identifies an authority that issues Certificates. An Issuer Certificate may identify a root CA or an intermediate CA. Certificates that identify root CAs are self-signed Certificates. Certificates that identify intermediate CAs are issued by authority identified by an intermediate CA or root CA.
The X.509 v3 fields in Issuer Certificates with specific requirements are shown in Table 48.
|
Field |
Description |
|
subject |
The distinguished name of for the authority. The Common Name attribute shall be specified. The Organization should be provided. Other attributes may be specified. |
|
authorityKeyIdentifier |
Provides more information about the key used to sign the Certificate. It shall be specified. |
|
basicConstraints |
The basicConstraints field is completely described in RFC 5280. The cA flag Identifies whether the subject of the Certificate is a CA The pathLength specifies the maximum depth of valid chains that include this Certificate. The cA flag shall be TRUE for CA Certificates. |
A Certificate Revocation List (CRL) is a ByteString containing the DER encoded form (see X690) of an X.509 v3 CRL. The CRL is issued by certifying authority and contains the serial numbers of the Certificates issued by that authority which are no longer valid. All CRLs shall have the extension defined in Table 46. The extension is defined completely in RFC 5280.
Table 49 – Certificate Revocation List Extensions
|
Extension |
Description |
|
authorityKeyIdentifier |
Provides more information about the key used to sign the CRL. |
Any X.509 v3 Certificate may be signed by CA which means that validating the signature requires access to the X.509 v3 Certificate belonging to the signing CA. Whenever an application validates a Certificate (see OPC 10000-4) it shall recursively build a chain of Certificates by finding the issuer Certificate, validating the Certificate and then repeat the process for the issuer Certificate. The chain ends with a self-signed Certificate.
The number of CAs used in a system should be small so it is common to install the necessary CAs on each machine with an OPC UA application. However, applications have the option of including a partial or complete chain whenever they pass a Certificate. This includes GetEndpoints, SecureChannel negotiation and during the CreateSession/ActivateSession handshake.
All OPC UA applications shall accept partial or complete chains in any field that contains a DER encoded Certificate.
Chains are stored in a ByteString by simply appending the DER encoded form of the Certificates. The first Certificate shall be the end Certificate followed by its issuer. If the root CA is sent as part of the chain, it is last Certificate appended to the ByteString.
Chains are parsed by extracting the length of each Certificate from the DER encoding. For Certificates with lengths less than 65 535 bytes it is an MSB encoded UInt16 starting at the 3rd byte.