The contents of the MessageChunkshall not be interpreted until the Messageis decrypted and the signature and sequence number verified.

If an error occurs during Messageverification the receiver shall close the communication channel. If the receiver is the Server,it shall also send a transport error Messagebefore closing the channel. Once the channel is closed the Clientshall attempt to re-open the channel and request a new SecurityTokenby sending an OpenSecureChannelrequest. The mechanism for sending transport errors to the Clientdepends on the communication channel.

The receiver shall first check the SecureChannelId. This value may be 0 if the Messageis an OpenSecureChannelrequest. For other Messages,it shall report a Bad_SecureChannelUnknownerror if the SecureChannelIdis not recognized. If the Messageis an OpenSecureChannelrequest and the SecureChannelIdis not 0 then the SenderCertificateshall be the same as the SenderCertificateused to create the channel.

If the Messageis secured with asymmetric algorithms, then the receiver shall verify that it supports the requested SecurityPolicy. If the Messageis the response sent to the Client,then the SecurityPolicyshall be the same as the one specified in the request. In the Server,the SecurityPolicyshall be the same as the one used to originally create the SecureChannel.

The receiver shall verify the ReceiverCertificateThumbprintand report a Bad_CertificateInvalid error if it does not recognize it.

The receiver shall check that the Certificateis trusted first and return Bad_SecurityChecksFailedon error. The receiver shall then verify the SenderCertificateusing the rules defined in OPC 10000-4. The receiver shall report the appropriate error if Certificatevalidation fails.

If the Messageis secured with symmetric algorithms, then a Bad_SecureChannel TokenUnknown error shall be reported if the TokenId refers to a SecurityTokenthat has expired or is not recognized.

If decryption or signature validation fails, then a Bad_SecurityChecksFailederror is reported. If an implementation allows multiple SecurityModesto be used the receiver shall also verify that the Messagewas secured properly as required by the SecurityModespecified in the OpenSecureChannelrequest.

After the security validation is complete the receiver shall verify the RequestIdand the SequenceNumber. If these checks fail a Bad_SecurityChecksFailederror is reported. The RequestId only needs to be verified by the Clientsince only the Clientknows if it is valid or not. If the SequenceNumberis not valid, the receiver shall log a Bad_SequenceNumberInvaliderror.

At this point the SecureChannelknows it is dealing with an authenticated Messagethat was not tampered with or resent. This means the SecureChannelcan return secured error responses if any further problems are encountered.

Stacksthat implement UASC shall have a mechanism to log errors when invalid Messagesare discarded. This mechanism is intended for developers, systems integrators and administrators to debug network system configuration issues and to detect attacks on the network.