HTTPS refers HTTP Messages exchanged over a TLS connection (see HTTPS). The syntax of the HTTP Messages does not change and the only difference is a TLS connection is created instead of a TCP/IP connection. This implies that profiles which use this transport can also be used with HTTP when security is not a concern.

HTTPS is a protocol that provides transport security. This means all bytes are secured as they are sent without considering the Message boundaries. Transport security can only work for point to point communication and does not allow untrusted intermediaries or proxy servers to handle traffic.

The SecurityPolicy shall be specified, however, it only affects the algorithms used for signing the Nonces during the CreateSession/ActivateSession handshake. A SecurityPolicy of None indicates that the Nonces do not need to be signed. The SecurityMode is set to Sign unless the SecurityPolicy is None; in this case the SecurityMode shall be set to None. If a UserIdentityToken is to be encrypted, it shall be explicitly specified in the UserTokenPolicy.

An HTTP Header called ‘OPCUA-SecurityPolicy’ is used by the Client to tell the Server what SecurityPolicy it is using if there are multiple choices available. The value of the header is the URI for the SecurityPolicy. If the Client omits the header, then the Server shall assume a SecurityPolicy of None.

All HTTPS communications via a URL shall be treated as a single SecureChannel that is shared by multiple Clients. Stacks shall provide a unique identifier for the SecureChannel which allows applications correlate a request with a SecureChannel. This means that Sessions can only be considered secure if the AuthenticationToken (see OPC 10000-4) is long (>20 bytes) and HTTPS encryption is enabled.

The cryptography algorithms used by HTTPS have no relationship to the EndpointDescription SecurityPolicy and are determined by the policies set for HTTPS and are outside the scope of OPC UA.

Figure 21 illustrates a few scenarios where the HTTPS transport could be used.

Figure 21 – Scenarios for the HTTPS Transport

In some scenarios, HTTPS communication will rely on an intermediary which is not trusted by the applications. If this is the case, then the HTTPS transport cannot be used to ensure security and the applications will have to establish a secure tunnel like a VPN before attempting any OPC UA related communication.

Applications which support the HTTPS transport shall support HTTP and TLS.

Some HTTPS implementations require that all Servers have a Certificate with a Common Name (CN) that matches the DNS name of the Server machine. This means that a Server with multiple DNS names will need multiple HTTPS certificates. If multiple Servers are on the same machine they may share HTTPS certificates. This means that ApplicationCertificates are not the same as HTTPS Certificates. Applications which use the HTTPS transport and require application authentication shall check application Certificates during the CreateSession/ActivateSession handshake.

HTTPS Certificates can be automatically generated; however, this will cause problems for Clients operating inside a restricted environment such as a web browser. Therefore, HTTPS certificates should be issued by an authority which is accepted by all web browsers which need to access the Server. The set of Certificate authorities accepted by the web browsers is determined by the organization that manages the Client machines. Client applications that are not running inside a web may use the trust list that is used for application Certificates.

HTTPS connections have an unpredictable lifetime. Therefore, Servers must rely on the AuthenticationToken passed in the RequestHeader to determine the identity of the Client. This means the AuthenticationToken shall be a randomly generated value with at least 32 bytes of data and HTTPS with signing and encryption shall always be used.

HTTPS allows Clients to have certificates; however, they are not required by the HTTPS transport. A Server shall allow Clients to connect without providing a Certificate during negotiation of the HTTPS connection.

HTTP 1.1 supports Message chunking where the Content-Length header in the request response is set to “chunked” and each chunk is prefixed by its size in bytes. All applications that support the HTTPS transport shall support HTTP chunking.

The URL scheme for endpoints using the HTTPS transport is ‘opc.https’. Note that ‘https’ is the generic URL scheme for the underlying transport. The opc prefix specifies that the endpoint accepts OPC UA messages as defined in this document.