本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
自签名证书的重定向说明
从基于 Web 的门户或应用程序重定向到 NICE DCV 会话时，如果自签名证书以前不受信任，该证书可能会破坏浏览器与会话的信任关系。以下是一个发生这种情况的示例：
用户连接到从中加载应用程序的公司门户站点。
该应用程序尝试使用自签名证书打开与 NICE DCV 服务器的直接安全连接。
浏览器拒绝该安全连接，因为证书是自签名的。
用户看不到远程服务器，因为未建立连接。
信任问题是步骤 3 特定的。在用户使用自签名证书连接到网站（例如，导航到 https://example.com）时，浏览器要求信任该证书。不过，通过 HTTP 或 HTTPS 提供服务的 Web 应用程序/页面尝试建立到 DCV 服务器的安全 WebSocket 连接。如果证书是自签名的，浏览器检查它以前是否受信任。如果证书以前不受信任，则会拒绝连接，而不会向用户发出请求，提示用户是否要信任该证书。
这种情况的可能解决方案：
具有 DCV 服务器计算机的有效证书 - 如果企业在其计算机中使用自定义域。对于证书，他们可以为 DCV 分发企业证书。
用户 ---[有效证书]---> DCV 服务器实例
在代理/网关中保护一组 DCV 服务器。仅在这种情况下，代理/网关需要具有有效的证书，并且 DCV 服务器实例可以保留其自签名证书。对于该选项，他们可以使用 DCV Connection Gateway、ALB/NLB 或其他代理解决方案。
用户/Cx ---[此处，我们需要有效的证书]---> 代理/网关---[自签名证书]---> DCV 服务器实例
在通过 SDK 启动连接之前，让用户信任自签名证书。只需在另一个选项卡/窗口/弹出窗口中打开该 URL，即可实现该目的：
https://example.com/version。注意
/version 终端节点在 HTTPS 连接中使用简单的网页进行响应，以表示 DCV 服务器版本。
以后，可以在实际 DCV 服务器连接中使用相同的自签名证书。