ORA-12650错误本质是客户端与服务端加密/校验算法无交集，需双向协商一致：客户端连接串必须显式指定encrypt=true、encryption_types、crypto_checksum_types等参数，且须与服务端sqlnet.ora中SQLNET.ENCRYPTION_TYPES_SERVER和SQLNET.CRYPTO_CHECKSUM_SERVER配置完全匹配。
ORA-12650 错误本质是加密算法协商失败
java 11 应用连接 oracle 19c 报 ora-12650: no common encryption or data integrity algorithm，不是驱动版本不对，而是客户端和服务端在加密/校验算法上没达成一致。oracle net 加密是双向协商机制：哪怕你只配了 sqlnet.encryption_client=required，服务端也必须支持同一种加密类型和校验方式，否则静默失败或直接报错。
ojdbc8 必须配合显式连接参数，不能依赖 sqlnet.ora
Oracle.ManagedDataAccess（.NET 场景常见）不读 sqlnet.ora，但 Java 的 JDBC 驱动同样不自动加载该文件——它只认连接字符串里的显式配置。尤其当你用的是 ojdbc8（比如 ojdbc8-19.21.0.0.jar），必须把加密要求“说清楚”，否则默认走明文协商，服务端拒绝。
- 连接 URL 中必须包含：
encrypt=true;crypto_checksum=true;encryption_types=(AES256);crypto_checksum_types=(SHA256) - 如果服务端
sqlnet.ora中设了SQLNET.ENCRYPTION_TYPES_SERVER=(AES192)，那你的连接串里就得改成(AES192)，否则协商失败 - JDK 11 默认禁用旧算法（如 RC4、DES），所以别在连接串里写
(RC4_256)——JVM 会直接抛java.security.NoSuchAlgorithmException
验证加密是否真生效，别信“连上了就行”
连接成功不代表加密启用。两个硬指标缺一不可：
- 查数据库侧视图：
SELECT network_service_banner FROM v$session_connect_info WHERE sid = (SELECT sid FROM v$mystat WHERE rownum = 1)，返回值里必须含encryption和具体算法名（如AES256） - 用
tnsping或抓包验证：启动时加-Doracle.net.enableO3=trueJVM 参数，再用 Wireshark 过滤oracle流量，确认 payload 不是明文 ASCII
最容易被忽略的是服务端 sqlnet.ora 中的 SQLNET.CRYPTO_CHECKSUM_SERVER 配置——如果它设为 REJECTED，哪怕客户端开了 crypto_checksum=true，也会降级为无校验，导致中间人篡改风险。这个开关必须和服务端策略对齐。
