HTTPS refers HTTP Messages exchanged over a SSL/TLS connection. 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 16 illustrates a few scenarios where the HTTPS transport could be used.
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 HTTP 1.1 and SSL/TLS 1.0.
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 clause.
Session-less Services (see OPC 10000-4) may be invoked via HTTPS POST. The HTTP Authorization header in the Request shall have a Bearer token which is an Access Token provided 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 TransportProtocol implements the OPC UA Services using a SOAP request-response message pattern over an HTTPS connection.
The body of the HTTP Messages shall 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 Message as an XML element. This element is added to the SOAP Message as the only child of the SOAP body element. If an error occurs in the Server while parsing the request body, the Server may return a SOAP fault or it may return an OPC UA error response.
The SOAP Action associated with an XML encoded request Message always has the form:
http://opcfoundation.org/UA/2008/02/Services.wsdl/<service name>
Where <service name> is the name of the OPC UA Service being invoked.
The SOAP Action associated with an XML encoded response Message always 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 TransportProtocol implements the OPC UA Services using an OPC UA Binary 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 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 Message body is the request or response structure encoded as an ExtensionObject in 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 Service the 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 TransportProtocol implements 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