一、问题现象

在启动 Java KVM / Java Web Start 应用时，弹出如下提示：

应用程序已被 Java 安全阻止
出于安全原因，应用程序现在必须满足“高”或“非常高”安全设置的要求或属于“例外站点列表”的一部分才能允许运行。

名称：com.kvm.viewer.Viewer
位置：https://***
原因：您的安全设置已阻止已签名的应用程序运行

此时：

• 没有“继续 / 运行”按钮
• 无法通过自动化（Playwright、PyJAB 等）绕过
• 应用直接被终止

二、这是 Java 安全机制的“硬阻断”

这不是程序 bug，也不是自动化工具的问题，而是 Java 的安全策略主动拦截。

该提示意味着：

Java 在 JVM 启动之前就拒绝了该应用

一旦出现这个窗口：

• JVM 不会创建
• Java Accessibility Bridge 不会加载
• 后续任何 UI 自动化都无效

三、触发该问题的直接原因

从 Java 官方安全模型角度，触发条件主要有以下几类：

1. 应用签名不被信任（最核心原因）

• 应用虽然“已签名”
• 但签名证书：
  • 过期
  • 自签名
  • 使用弱算法（SHA1）
  • 证书链不完整
• Java 8u51 以后 默认不再信任此类签名

结论：“已签名 ≠ 被信任”

2. 使用 IP 地址 + HTTPS 访问

Java 安全策略中：

• HTTPS + IP 地址，不被视为“可信主机名”
• 证书中的 CN / SAN 与 IP 不匹配

Java 会认为：存在中间人风险（MITM）

3. 安全级别为 High / Very High

在 Java 控制面板中：

• High / Very High：
  • 禁止运行未在白名单中的应用
  • 不会弹“是否继续”
  • 直接阻断

4. 自动化启动方式加重了风险判定（次要但常见）

在以下场景更容易被直接阻止：

• 浏览器自动下载 .jnlp
• 自动执行 Java Web Start
• 无明显人工交互

Java 会更倾向于走“保守策略”。

四、为什么有时“能点继续”，有时却被直接阻止？

这是很多人困惑的点，关键在于拦截发生的阶段不同：

一旦进入“硬拦截”，任何自动化手段都无效

五、推荐的解决方案

方案一：使用 Exception Site List

这是官方推荐、最稳妥的方式。

操作步骤

1. 打开 Java 控制面板
2. 进入 Security
3. 安全级别设置为：High
4. 点击 Exception Site List
5. 添加访问地址（示例）：https://<*******>

效果：

• 不再出现“已被安全阻止”
• Java 恢复弹出正常安全确认
• 自动化可继续接管

方案二：部署自签 CA 或使用可信证书

适合长期方案：

• 给 Java 应用重新签名
• 使用企业 CA 或可信证书
• CN / SAN 与访问域名匹配

优点：

• 不需要 Exception List
• 符合安全规范

缺点：

• 成本高
• 需要供应商支持

方案三：绕过浏览器，直接 javaws 启动

自动化场景建议：

1. 浏览器仅负责下载.jnlp
2. 使用命令行启动：

javaws -silent viewer.jnlp

优点：

• 避免浏览器安全链
• Java 更容易进入“可交互安全提示”状态
• 兼容 UI 自动化

“应用程序已被 Java 安全阻止”不是弹窗问题，而是 JVM 启动权限问题。 解决问题的关键不在自动化，而在 Java
安全信任链的正确配置。