本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
自签名证书的重定向说明
从基于 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 服务器连接中使用相同的自签名证书。