MySQL兼容Amazon Aurora加密客户端连接原理咨询

一、无CA证书仍能建立加密连接的核心原因 #

TLS连接建立分为加密通道协商和身份验证两个独立阶段。当你将MySQL Workbench的“Use SSL”设为“Require”时，仅要求客户端与服务器建立加密传输通道，但跳过了服务器证书的可信链验证环节：

• Amazon Aurora MySQL实例默认搭载AWS自有CA签发的服务器证书，客户端发起TLS连接请求时，服务器会自动推送该证书。
• 未指定CA文件时，客户端（包括Workbench、CLI、应用驱动）仅会检查证书的基础有效性（如有效期、域名匹配），不会验证证书是否由可信机构签发，只要加密套件协商成功，就会建立加密连接——这就是你能看到TLSv1.2和指定加密套件的原因，通道确实是加密的，但未验证服务器身份。

二、“Require and Verify CA/Identity”连接失败的原因 #

开启证书验证模式时，客户端需要通过指定的CA文件校验服务器证书的签发链：

• Aurora使用的是AWS官方根CA（如Amazon RDS Root CA 2019/2024），若客户端未配置对应CA文件，无法确认服务器证书的合法性，直接拒绝连接。
• “Require and Verify Identity”还额外要求证书的CN/SAN字段与数据库端点完全匹配，这一步同样依赖可信CA的验证支撑，无CA文件时自然无法通过。

三、多客户端无证书连接的共性逻辑 #

所有MySQL客户端库（如libmysqlclient、mysql-connector-java）默认支持“仅加密、不验证证书”的模式：

• MySQL CLI中，使用--ssl-mode=REQUIRED参数（对应Workbench的“Use SSL: Require”），无需指定--ssl-ca即可建立加密连接，但不做证书验证。
• Lambda、EC2等AWS内部服务的客户端，若使用官方驱动或SDK，默认也不会强制验证CA，除非显式配置CA文件和验证模式。

四、生产环境安全加固建议 #

当前加密连接虽能防止明文传输，但跳过证书验证存在**中间人攻击（MITM）**风险——攻击者可伪造Aurora服务器证书，拦截并窃取加密数据，必须做以下加固：

1. 强制证书验证
   • 下载对应版本的AWS RDS/Aurora根CA文件，分发给所有客户端。
   • 客户端配置开启验证模式：
     • MySQL Workbench：指定CA文件路径，选择“Require and Verify CA”
     • MySQL CLI：执行mysql --ssl-mode=VERIFY_CA --ssl-ca=/path/to/rds-ca.pem -h <端点> -u <用户>
     • 应用驱动：配置CA证书路径并开启验证（如Java驱动设置useSSL=true&requireSSL=true&verifyServerCertificate=true&sslCa=/path/to/rds-ca.pem）
2. 启用IAM数据库认证（推荐）
   针对Lambda、EC2等AWS内部服务，启用IAM数据库认证，无需管理数据库密码，结合TLS验证进一步提升安全等级。
3. 限制端点访问范围
   通过安全组、网络ACL仅允许信任的IP或VPC访问Aurora端点，缩小攻击面。
4. 定期更新CA证书
   AWS会定期更新RDS/Aurora的CA证书，需及时替换客户端的CA文件，避免证书过期导致连接中断。

内容的提问来源于stack exchange，提问作者David Simms