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 会更倾向于走“保守策略”。

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

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

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

五、推荐的解决方案

方案一：使用 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
安全信任链的正确配置。

总结 

到此这篇关于Java应用程序已被安全阻止提示原因分析与解决方案的文章就介绍到这了,更多相关Java应用程序已被安全阻止提示内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论