WebSockets requires that the Serverhave a Certificate, however, the Clientmay have a Certificate. The Server Certificateshould have the domain name as the common name component of the subject name, however, Clientsthat are able to override the Certificatevalidation procedure can choose to accept Certificateswith a domain mismatch.

When using the WebSockets transport from a web browser the browser environment may impose additional restrictions. For example, the web browser may require the Serverhave a valid TLS Certificatethat is issued by CA that is installed in the Trust Listfor the web browser. To support these Clients,a Servermay use a TLS Certificatethat does not conform to the requirements for an ApplicationInstance Certificate. In these cases, the TLS Certificateis only used for TLS negotiation and the Servershall use a valid ApplicationInstance Certificate for other interactions that require one. Serversshall allow adminstrators to specify a Certificatefor use with TLS that is different from from the ApplicationInstance Certificate.

Clientsrunning in a browser environment specify the ‘Origin’ HTTP header during the WebSocketupgrade handshake. Serversshould return the ‘Access-Control-Allow-Origin’ to indicate that the connection is allowed.

Any Clientthat does not run in a web browser environment and supports the WebSockets transport shall accept OPC UA Application Instance Certificateas the TLS Certificateprovided the correct domain is specified in the subjectAltNamefield.

A Clientmay use its Application Instance Certificate as the TLS Certificateand Serversshall accept those Certificatesif they are valid according to the OPC UA Certificatevalidation rules.

Some operating systems will not give the application any control over the set of algorithms that TLS will negotiate. In some cases, this set will be based on the needs of web browsers and will not be appropriate for the needs of an OPC UA Application. If this is a concern, applications should use OPC UA Secure Conversation in addition to TLS.

Clients that support the WebSocket transport shall support explicit configuration of an HTTPS proxy. When using an HTTPS proxy the Clientshall first send an HTTP CONNECT message (see HTTP) before starting the WebSocket protocol handshake. Note that explicit HTTPS proxies allow for man-in-the-middle attacks. This threat may be mitigated by using OPC UA Secure Conversation in addition to TLS.