oracle 19c rac集群本身不因ssl证书过期停机，真正受影响的是启用ssl的监听器、oracle wallet证书或客户端ssl连接；需先用crsctl check cluster -all等命令确认集群及实例正常，再定位wallet中过期的中间ca证书并滚动更新。
Oracle 19c RAC 集群本身不会因 SSL 证书过期而停机。集群服务（CRS、CSSD、EVMD 等）默认不依赖 SSL/TLS 加密通信；真正受影响的是：启用 SSL 的数据库监听器（listener.ora 中配置了 SSL_VERSION 或 WALLET_LOCATION）、Oracle Wallet 中的证书、或客户端（如 JDBC、SQL*Plus）通过 SSL 连接数据库实例时的握手失败。所谓“集群停机”，往往是误判——实际是应用连不上数据库，或 DBA 用 SSL 方式远程管理时被拒绝。
确认是不是真由 SSL 证书触发的故障
别一看到报错就去翻证书。先验证集群底层是否健康：
- 用
crsctl check cluster -all查所有节点 CRS 状态，若返回CRS-4537: Cluster Ready Services is online，说明集群没停 - 查数据库实例：
srvctl status database -d <db_name></db_name>，如果显示Instance <inst> is running on node <node></node></inst>，说明实例活着 - 检查监听器状态：
lsnrctl status LISTENER_SSL（或你命名的 SSL 监听器名），重点看输出里有没有SSL version: TLSv1.2和Wallet location行 - 抓取监听器日志：
tail -n 50 $ORACLE_HOME/network/log/listener_ssl.log，搜索SSL handshake failed或CertificateExpiredException
如果以上都正常，但应用报“connection refused”或“PKIX path building failed”，那问题在客户端信任链，不是集群停机。
定位 Oracle Wallet 中哪张证书过期
RAC 环境中 SSL 通常靠 Oracle Wallet（ewallet.p12）统一管理，而非 JVM truststore。过期的往往不是服务器证书，而是 Wallet 里包含的中间 CA 证书 —— 它有效期常比服务器证书短，且容易被忽略。
- 进入 Wallet 目录：
$ORACLE_HOME/admin/<db_name>/wallet</db_name>（或监听器配置中WALLET_LOCATION指定路径） - 导出所有证书：
orapki wallet display -wallet . -pwd <wallet_pwd></wallet_pwd>，记下每个证书的Subject和Trusted Certificates列表 - 逐个导出为 PEM：
orapki wallet export_trusted_certificates -wallet . -pwd <pwd> -dn "CN=Intermediate CA, O=MyOrg"</pwd> - 查每张证书有效期：
openssl x509 -in intermediate.crt -noout -dates，特别注意notAfter是否早于2026-08-27
常见坑：Wallet 里只导入了服务器证书，漏掉中间 CA；或用 orapki wallet add -trusted_cert 时没加 -dn 参数导致别名混乱，后续无法精准替换。
更新 Wallet 并滚动重启监听器（RAC 安全操作）
不能直接停整个集群去改 Wallet。必须按节点滚动操作，避免业务中断：
- 先在节点1停 SSL 监听器：
srvctl stop listener -l LISTENER_SSL -n node1 - 备份原 Wallet：
cp ewallet.p12 ewallet.p12.bak.$(date +%F) - 删除旧中间 CA：
orapki wallet remove -trusted_cert -wallet . -dn "CN=Old Intermediate CA" - 导入新中间 CA 和服务器证书（顺序无关，但必须都导入）：
orapki wallet add -trusted_cert -wallet . -certificate intermediate_new.crt -pwd <pwd></pwd>，再执行同样命令导入server.crt - 重启该节点监听器：
srvctl start listener -l LISTENER_SSL -n node1 - 验证连接：
sqlplus /@<tns_alias_for_node1_ssl></tns_alias_for_node1_ssl>，成功后再对 node2 执行相同流程
关键点：不要用 srvctl stop listener -l LISTENER_SSL（无 -n），那会同时停两个节点；也不要修改 Wallet 后不重启监听器——Wallet 内容只在监听器启动时加载一次。
为什么 JDBC 应用还是连不上？检查客户端侧的 cacerts
即使 RAC 监听器证书已更新，Java 应用仍可能报 CertificateExpiredException，因为 JVM 还在用旧的 cacerts：
- 确认应用实际运行的 JDK：
ps aux | grep java | grep -v grep | grep -o 'java-\d\+-.*'，别只改/usr/lib/jvm/java-8-openjdk却跑在java-17-amazon-corretto上 - 从监听器端导出完整证书链：
openssl s_client -connect node1:1521 -showcerts -servername your-scan-name 2>/dev/null | openssl x509 -outform PEM > full_chain.pem - 拆分
full_chain.pem（每段-----BEGIN CERTIFICATE-----保存为单独文件），对每张证书运行openssl x509 -in cert1.pem -noout -dates - 用
keytool -importcert -file cert1.pem -alias oracle-intermediate-1 -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit逐个导入（包括中间 CA）
最易被忽略的细节：RAC 的 SCAN 名称解析到多个 IP，但 openssl s_client 默认只连第一个；务必加 -servername 参数并指定真实 SCAN 域名，否则抓到的可能是非 SSL 监听器的响应。
