HTTPSrefers HTTP Messagesexchanged over a SSL/TLSconnection. 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 16illustrates a few scenarios where the HTTPS transport could be used.

image019.png

Figure 16– 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 HTTP1.1 and SSL/TLS1.0.

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 clause.

Session-less Services (see OPC 10000-4) may be invoked via HTTPS POST. The HTTP Authorizationheader in the Requestshall have a Bearer token which is an Access Tokenprovided by the Authorization Service. The Content-type of the HTTP request shall specify the encoding of the body. If the Content-type is application/opcua+uabinary then the body is encoded using the OPC UA Binary encoding (see 7.4.4). If the Content-type is application/opcua+uajson then body is encoded using the reversible form of the JSON encoding (see 7.4.5).

Note that the Content-type for OPC UA Binary encoded bodies for Session-less Services is different from the Content-type for Session-based Services specified in 7.4.4.

This TransportProtocolimplements the OPC UA Servicesusing a SOAP request-response message pattern over an HTTPS connection.

The body of the HTTP Messagesshall be a SOAP 1.2 Message(see SOAP Part 1). WS-Addressing headers are optional.

The OPC UA XML Encoding specifies a way to represent an OPC UA Messageas an XML element. This element is added to the SOAP Messageas the only child of the SOAP body element. If an error occurs in the Serverwhile parsing the request body, the Servermay return a SOAP fault or it may return an OPC UA error response.

The SOAP Action associated with an XML encoded request Messagealways has the form:

http://opcfoundation.org/UA/2008/02/Services.wsdl/<service name>

Where <service name> is the name of the OPC UA Servicebeing invoked.

The SOAP Action associated with an XML encoded response Messagealways has the form:

http://opcfoundation.org/UA/2008/02/Services.wsdl/<service name>Response

All requests shall be HTTP POST requests. The Content-type shall be "application/soap+xml" and the charset and action parameters shall be specified. The charset parameter shall be "utf-8" and the action parameter shall be the URI for the SOAP action.

An example HTTP request header is:

POST /UA/SampleServer HTTP/1.1

Content-Type: application/soap+xml; charset="utf-8";

action="http://opcfoundation.org/UA/2008/02/Services.wsdl/Read"

Content-Length: nnnn

The action parameter appears on the same line as the Content-Type declaration.

An example request Message:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">

<s:Body>

<ReadRequest xmlns="http://opcfoundation.org/UA/2008/02/Types.xsd">

</ReadRequest>

</s:Body>

</s:Envelope>

An example HTTP response header is:

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset="utf-8";

action="http://opcfoundation.org/UA/2008/02/Services.wsdl/ReadResponse"

Content-Length: nnnn

The action parameter appears on the same line as the Content-Type declaration.

An example response Message:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">

<s:Body>

<ReadResponse xmlns="http://opcfoundation.org/UA/2008/02/Types.xsd">

</ReadResponse>

</s:Body>

</s:Envelope>

This TransportProtocolimplements the OPC UA Servicesusing an OPC UA Binary Encoded Messagesexchanged over an HTTPS connection.

Applications which support the HTTPS Profileshall support HTTP 1.1.

The body of the HTTP Messagesshall be OPC UA Binary encoded blob. The Content-type shall be "application/octet-stream".

An example HTTP request header is:

POST /UA/SampleServer HTTP/1.1

Content-Type: application/octet-stream;

Content-Length: nnnn

An example HTTP response header is:

HTTP/1.1 200 OK

Content-Type: application/octet-stream;

Content-Length: nnnn

The Messagebody is the request or response structure encoded as an ExtensionObjectin OPC UA Binary. The Authorization header is only used for Session-less Service calls (see 7.4.2).

If the OPC UA Binary Encoding is used for a Session-less Servicethe HTTP request header is:

POST /UA/SampleServer HTTP/1.1 Authorization : Bearer <base64-encoded-token-data>

Content-Type: application/opcua+uabinary;

Content-Length: nnnn

This TransportProtocolimplements the OPC UA Services using JSON encoded Messages exchanged over an HTTPS connection.

Applications which support the HTTPS Profile shall support HTTP 1.1.

The body of the HTTP Messages shall be OPC UA JSON Encoded. The Content-type shall be "application/opcua+uajson".

An example HTTP request header is:

POST /UA/SampleServer HTTP/1.1 Authorization : Bearer <base64-encoded-token-data>

Content-Type: application/opcua+uajson;

Content-Length: nnnn

An example HTTP response header is:

HTTP/1.1 200 OK

Content-Type: application/opcua+uajson; Content-Length: nnnn