Most Messages require a SecureChannel to be established. A Client does this by sending an OpenSecureChannel request to the Server. The Server shall validate the Message and the ClientCertificate and return an OpenSecureChannel response. Some of the parameters defined for the OpenSecureChannel service are specified in the security header (see 6.7.2) instead of the body of the Message. Table 60 lists the parameters that appear in the body of the Message.

Note that OPC 10000-4 is an abstract specification which defines interfaces that can work with any protocol. This document provides a concrete implementation for specific protocols. This document is the normative reference for all protocols and takes precedence if there are differences with OPC 10000-4.

Table 60 – OPC UA Secure Conversation OpenSecureChannel Service

Name	Data Type
Request
RequestHeader	RequestHeader
ClientProtocolVersion	UInt32
RequestType	SecurityTokenRequestType
SecurityMode	MessageSecurityMode
ClientNonce	ByteString
RequestedLifetime	UInt32
Response
ResponseHeader	ResponseHeader
ServerProtocolVersion	UInt32
SecurityToken	ChannelSecurityToken
SecureChannelId	UInt32
TokenId	UInt32
CreatedAt	UtcTime
RevisedLifetime	UInt32
ServerNonce	ByteString

The ClientProtocolVersion and ServerProtocolVersion parameters are not defined in OPC 10000-4 and are added to the Message to allow backward compatibility if OPC UA-SecureConversation needs to be updated in the future.

If OPC UA-SecureConversation is used with the OPC UA-TCP protocol (see 7.1) then the ClientProtocolVersion specified in the OpenSecureChannel Request shall be the same as the ProtocolVersion specified in the Hello Message. In addition, the ServerProtocolVersion specified in the OpenSecureChannel Response shall be the same as the ProtocolVersion specified in the Acknowledge Message. The receiver shall close the channel and report a Bad_ProtocolVersionUnsupported error if there is a mismatch.

The Server shall return an error response as described in OPC 10000-4 if there are any errors with the parameters specified by the Client.

The RevisedLifetime tells the Client when it shall renew the SecurityToken by sending another OpenSecureChannel request. The Client shall continue to accept the old SecurityToken until it expires or it receives a Message from the Server secured with the new SecurityToken. The Client shall send a Messages secured with new SecurityToken as soon as it finishes processing the OpenSecureChannel response. The Client shall close the SecureChannel if the Certificate used to sign the response is not the same as the Certificate used to encrypt the request.

The Server shall accept requests secured with the old SecurityToken until that SecurityToken expires or until it receives a Message from the Client secured with the new SecurityToken. The Server shall reject renew requests if the SenderCertificate is not the same as the one used to create the SecureChannel or if there is a problem decrypting or verifying the signature.

The datatype of the RevisedLifetime is a UInt32 value representing the number of milliseconds instead of the Double (Duration) defined in OPC 10000-4. This optimization is possible because sub-millisecond timeouts are not supported.

The OpenSecureChannel Messages are signed and encrypted if the SecurityMode is not None (even if the SecurityMode is Sign).

The Nonces shall be cryptographic random numbers with a length specified by the SecureChannelNonceLength of the SecurityPolicy.

See OPC 10000-2 for more information on the requirements for random number generators. The OpenSecureChannel Messages are not signed or encrypted if the SecurityMode is None. The Nonces are ignored and should be set to null. The SecureChannelId and the TokenId are still assigned but no security is applied to Messages exchanged via the channel. The SecurityToken shall still be renewed before the RevisedLifetime expires. Receivers shall still ignore invalid or expired TokenIds.

The AuthenticationToken in the RequestHeader shall be set to null.

If an error occurs after the Server has verified Message security it shall return a ServiceFault instead of a OpenSecureChannel response. The ServiceFault Message is described in OPC 10000-4.

If the SecurityMode is not None then the Server shall verify that a SenderCertificate and a ReceiverCertificateThumbprint were specified in the SecurityHeader.