
Aurora MySQL 3.14 Has Been Released, So I Checked the Changes and Tried Out PQ Key Exchange
This page has been translated by machine translation. View original
Introduction
On November 2, 2026, the GA of Aurora MySQL 3.14.0, which is compatible with MySQL 8.0.46, was announced.
The previous version, 3.13, was introduced in the following article.
This article covers the PQ (post-quantum) key exchange added in 3.14.0. I connected via JDBC from Amazon Corretto 27 to a newly created cluster and checked the negotiation result of the key exchange group.
What's updated in 3.14.0
3.14.0 was released on October 26, 2026, and its end of standard support date is October 27, 2027 (the end of standard support for major version 3 is April 30, 2028).
3.14.0 adds X25519MLKEM768 and SecP256r1MLKEM768 as TLS 1.3 hybrid key exchange groups. Supported clients automatically negotiate these groups, and unsupported clients use the conventional groups. The group selected for each connection can be checked with the following command.
SHOW STATUS LIKE 'Aurora_ssl_named_group';
Apart from PQ key exchange, the release centers on fixes for high-severity CVEs, and also includes RETURNING clause support for single-table DELETE, additional CloudWatch metrics, and more. For details, see the release notes.
Verification method
Configuration
I connected via JDBC from EC2 to a newly created Aurora MySQL 3.14.0 cluster.
| Item | Value |
|---|---|
| Aurora MySQL | 3.14.0 (8.0.mysql_aurora.3.14.0, MySQL 8.0.46 compatible) |
| Cluster | One db.t4g.medium writer |
| Parameter group | default.aurora-mysql8.0 (default) |
| Region | ap-northeast-1 |
| Client | EC2 t4g.micro, Amazon Linux 2023 (aarch64) |
| JDBC driver | MySQL Connector/J 26.10.0 |
| Connection setting | sslMode=REQUIRED |
| Corretto | 27.0.1.0.11 |
Corretto is the latest build obtained from corretto.aws/downloads/latest/ as of November 3, 2026.
Connecting and capturing logs
For the verification, I used Probe.java, which connects via JDBC and runs seven queries. I ran it with -Djavax.net.debug=ssl:handshake added to the java command to output the TLS handshake log. The user name and password are passed through the environment variables DB_USER and DB_PASS.
java -Djavax.net.debug=ssl:handshake -cp mysql-connector-j-26.10.0.jar Probe.java <クラスターエンドポイント>
Probe.java
import java.sql.*;
public class Probe {
static void q(Statement st, String sql) throws SQLException {
System.out.println("=== QUERY: " + sql);
try (ResultSet rs = st.executeQuery(sql)) {
int n = rs.getMetaData().getColumnCount();
while (rs.next()) {
StringBuilder sb = new StringBuilder();
for (int i = 1; i <= n; i++) {
if (i > 1) sb.append(" | ");
sb.append(rs.getString(i));
}
System.out.println(sb);
}
}
}
public static void main(String[] a) throws Exception {
String host = a[0];
String url = "jdbc:mysql://" + host + ":3306/?sslMode=REQUIRED";
System.out.println("=== JAVA: " + System.getProperty("java.vendor.version")
+ " / java.version=" + System.getProperty("java.version"));
try (Connection c = DriverManager.getConnection(url, System.getenv("DB_USER"), System.getenv("DB_PASS"));
Statement st = c.createStatement()) {
System.out.println("=== DRIVER: " + c.getMetaData().getDriverName() + " " + c.getMetaData().getDriverVersion());
q(st, "SELECT VERSION()");
q(st, "SELECT aurora_version()");
q(st, "SHOW VARIABLES LIKE 'tls%'");
q(st, "SHOW VARIABLES LIKE 'ssl%'");
q(st, "SHOW STATUS LIKE 'Ssl_version'");
q(st, "SHOW STATUS LIKE 'Ssl_cipher'");
q(st, "SHOW STATUS LIKE 'Aurora_ssl_named_group'");
}
}
}
sslMode=REQUIRED requires an encrypted connection but does not verify the server certificate. Since the goal is to check the key exchange group, I used this setting this time.
Verification results
I connected with Corretto 27.0.1.0.11.
The query output is as follows. In the results of SHOW VARIABLES LIKE 'ssl%', the ssl_cipher row is omitted because the list of cipher suites is long.
=== QUERY: SELECT VERSION()
8.0.46
=== QUERY: SELECT aurora_version()
3.14.0
=== QUERY: SHOW VARIABLES LIKE 'tls%'
tls_ciphersuites |
tls_version | TLSv1.2,TLSv1.3
=== QUERY: SHOW VARIABLES LIKE 'ssl%'
ssl_ca | /rdsdbdata/rds-metadata/ca-cert.pem
ssl_capath |
ssl_cert | /rdsdbdata/rds-metadata/server-cert.pem
ssl_crl |
ssl_crlpath |
ssl_fips_mode | ON
ssl_key | /rdsdbdata/rds-metadata/server-key.pem
ssl_session_cache_mode | ON
ssl_session_cache_timeout | 300
=== QUERY: SHOW STATUS LIKE 'Ssl_version'
Ssl_version | TLSv1.3
=== QUERY: SHOW STATUS LIKE 'Ssl_cipher'
Ssl_cipher | TLS_AES_256_GCM_SHA384
=== QUERY: SHOW STATUS LIKE 'Aurora_ssl_named_group'
Aurora_ssl_named_group | X25519MLKEM768
The variables starting with tls and ssl do not include any item for switching PQ key exchange. Even with the default parameter group left as is, the value of Aurora_ssl_named_group was X25519MLKEM768.
The groups offered by the client can be checked in supported_groups (10) of the ClientHello in the handshake log. The group chosen by the server appears in server_share of the ServerHello.
"supported_groups (10)": {
"named groups": [X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096]
"key_share (51)": {
"server_share": {
"named group": X25519MLKEM768
Corretto 27 offered X25519MLKEM768 first, and the server chose the same group.
Summary
Aurora MySQL 3.14.0, compatible with MySQL 8.0.46, has been released. The LTS versions are 3.04 and 3.10, and the other 3.x minor versions (3.08 / 3.11 / 3.12 / 3.13 / 3.14, etc.) are non-LTS. If you are using a non-LTS version from 3.08 through 3.13, I recommend migrating to 3.14, which includes fixes for high-severity CVEs.
