MySQL Bugs: #119471: "Bad handshake" during each connection to a replication source server

Bug #119471	"Bad handshake" during each connection to a replication source server
Submitted:	27 Nov 2025 17:03
Reporter:	action mystique	Email Updates:
Status:	Open	Impact on me:	None
Category:	MySQL Server: Connection Handling	Severity:	S2 (Serious)
Version:	8.4.7	OS:	Ubuntu (25.10 questing)
Assigned to:		CPU Architecture:	x86 (64 bits)

Description:
The MySQL source server logs "Bad handshakes" during all TLS connections from a replica which uses the exact same server version in the exact same OS environment.

The replication wireshark trace logs all packets exchanged as soon as the replica starts the replication for the first try: https://drive.google.com/file/d/1ehNaX412ZA_NfNe7-nIWdxZDRJkLwYcI/view?usp=sharing 
mysql1-kvm is the source and mysql2-kvm is the replica.
I find it strange that the replica sends a login request with an **empty** username despite being correctly configured for the replication with a non-empty source username.

Maybe this issue is linked to the TLS **wildcard** certificate from Let's Encrypt which has undergone several changes as detailed here: https://letsencrypt.org/docs/profiles/#tlsserver

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            xxxx
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R12
        Validity
            Not Before: Oct  1 11:12:05 2025 GMT
            Not After : Dec 30 11:12:04 2025 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    xxxx
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                xxxx
            Authority Information Access: 
                CA Issuers - URI:http://r12.i.lencr.org/
            X509v3 Subject Alternative Name: critical
                DNS:*.sdxlive.com, DNS:sdxlive.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://r12.c.lencr.org/98.crl

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : xxxx
                    Timestamp : Oct  1 12:10:35.786 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                xxxx
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : xxxx
                    Timestamp : Oct  1 12:10:35.786 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                xxxx
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        xxxx

As you can see among other removals, the **Common Name has been omitted**, as it is redundant with the Subject Alternative Names and is marked as NOT RECOMMENDED by the Baseline Requirements to reflect the latest recommendations from the CA/Browser Forum.
These changes may throw off MySQL server.

There was no such issue with MySQL 8.0 using an older TLS certificate format.
I haven't tested MySQL 8.4 with the older TLS certificate format.

Please let me know if you need any more details.

How to repeat:
1. install mysql server 8.4.7-0ubuntu0.25.10.2 on the source using Ubuntu questing, configure it and start it
2. install mysql server 8.4.7-0ubuntu0.25.10.2 on the replica using Ubuntu questing, configure it and start it
3. show the replica status 

Suggested fix:
Take into account the new TLS certificate format to reflect the latest recommendations from the CA/Browser Forum

> I find it strange that the replica sends a login request with an **empty** username despite being correctly configured for the replication with a non-empty source username.

The SSL Handshake is described here: https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html#sect...

The login with empty username you see is a Protocol::SSLRequest and is documented here: https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_packets_p...

So basically what happens is this:
< Client (replica) connects over TCP, without TLS >
S → C Server Greeting
S ← C Login Request (Protocol::SSLRequest) No username, connection attributes, etc
< Now the TLS handshake happens >
S → C Server Greeting
S ← C Login Request (Protocol::HandshakeResponse41, with username etc)
< conversation continues >

Note that Wireshark can decode TLS traffic. For this it needs to be configured with the private key. For Diffie-Hellman based algorithms it will need the session key. So best to avoid those. See also Bug #80709

You may want to:
- Try what happens without TLS if that is acceptable for a short time.
- Configure Wireshark to decode TLS (https://wiki.wireshark.org/TLS, https://databaseblog.myname.nl/2014/07/decoding-encrypted-mysql-traffic-with.html). Use TLSv1.2 with AES256-SHA or something similar.
- Inspect the logs
- Try to reproduce this on a test setup, so it is easier to share the pcap and TLS credentials, etc.

Note: What MySQL calls SSL is TLS, MySQL never supported SSL.

I think the TLS part might not be the problem here.

Can you share more information about:
- The exact version of the primary and replica
- The exact CHANGE REPLICATION SOURCE TO statement (but without the actual password)
- Any logging and output that might be helpful