HTTPSrefers HTTP Messagesexchanged over a SSL/TLSconnection (see HTTPS). The syntax of the HTTP Messagesdoes 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 Messageboundaries. Transport security can only work for point to point communication and does not allow untrusted intermediaries or proxy servers to handle traffic.

The SecurityPolicyshall be specified, however, it only affects the algorithms used for signing the Noncesduring the CreateSession/ActivateSessionhandshake. A SecurityPolicyof Noneindicates that the Noncesdo not need to be signed. The SecurityModeis set to Signunless the SecurityPolicyis None; in this case the SecurityModeshall 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 Clientto tell the Serverwhat SecurityPolicyit is using if there are multiple choices available. The value of the header is the URI for the SecurityPolicy. If the Clientomits the header, then the Servershall assume a SecurityPolicyof None.

All HTTPS communications via a URL shall be treated as a single SecureChannelthat is shared by multiple Clients. Stacksshall provide a unique identifier for the SecureChannel which allows applications correlate a request with a SecureChannel.This means that Sessionscan 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 SecurityPolicyand are determined by the policies set for HTTPS and are outside the scope of OPC UA.

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

image022.png

Figure 19– 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 HTTPand SSL/TLS.

Some HTTPS implementations require that all Servershave a Certificatewith a Common Name (CN) that matches the DNS name of the Servermachine. This means that a Serverwith multiple DNS names will need multiple HTTPS certificates. If multiple Serversare on the same machine they may share HTTPS certificates. This means that ApplicationCertificatesare not the same as HTTPS Certificates. Applications which use the HTTPS transport and require application authentication shall check application Certificatesduring the CreateSession/ActivateSessionhandshake.

HTTPS Certificatescan 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 Certificateauthorities accepted by the web browsers is determined by the organization that manages the Clientmachines. Clientapplications 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, Serversmust rely on the AuthenticationTokenpassed in the RequestHeaderto determine the identity of the Client. This means the AuthenticationTokenshall be a randomly generated value with at least 32 bytes of data and HTTPS with signing and encryption shall always be used.

HTTPS allows Clientsto have certificates; however, they are not required by the HTTPS transport. A Servershall allow Clientsto connect without providing a Certificateduring negotiation of the HTTPS connection.

HTTP 1.1 supports Messagechunking 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.