Java 应用程序已被安全阻止 —— 原因分析与解决方案
一、问题现象
在启动 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 会更倾向于走“保守策略”。
四、为什么有时“能点继续”，有时却被直接阻止？
这是很多人困惑的点，关键在于 拦截发生的阶段不同：
| 阶段 | 行为 |
|---|---|
| 弹出“安全警告” | 软拦截（允许用户确认） |
| 显示“已被 Java 安全阻止” | 硬拦截（JVM 未启动） |
一旦进入“硬拦截”，任何自动化手段都无效
五、推荐的解决方案
方案一：使用 Exception Site List
这是官方推荐、最稳妥的方式。
操作步骤
- 打开 Java 控制面板
- 进入 Security
- 安全级别设置为：High
- 点击 Exception Site List
- 添加访问地址（示例）：
https://<*******>
效果：
- 不再出现“已被安全阻止”
- Java 恢复弹出正常安全确认
- 自动化可继续接管
方案二：部署自签 CA 或使用可信证书
适合长期方案：
- 给 Java 应用重新签名
- 使用企业 CA 或可信证书
- CN / SAN 与访问域名匹配
优点：
- 不需要 Exception List
- 符合安全规范
缺点：
- 成本高
- 需要供应商支持
方案三：绕过浏览器，直接 javaws 启动
自动化场景建议：
- 浏览器仅负责下载
.jnlp - 使用命令行启动：
javaws -silent viewer.jnlp 优点：
- 避免浏览器安全链
- Java 更容易进入“可交互安全提示”状态
- 兼容 UI 自动化
“应用程序已被 Java 安全阻止”不是弹窗问题，而是 JVM 启动权限问题。 解决问题的关键不在自动化，而在 Java
安全信任链的正确配置。
