[CONC-527] Connect error "SEC_E_ALGORITHM_MISMATCH" from Windows to Ubuntu server Created: 2021-02-18  Updated: 2023-03-12  Resolved: 2021-09-27

Status: Closed
Project: MariaDB Connector/C
Component/s: TLS/SSL
Affects Version/s: 3.1.11
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Martin Baxter Assignee: Vladislav Vaintroub
Resolution: Not a Bug Votes: 0
Labels: connection, error, tls
Environment:

Client is Windows 10, Server is MariaDB 10.5.8 on Ubuntu 20.04

Attachments: PNG File image-2021-09-25-18-55-02-471.png     File rootCA2.crt     File sqlclient2.crt     File sqlclient2.key     File sqlserver2.crt     File sqlserver2.key     File wsl2_handshake_bad.pcap    
Issue Links:
Duplicate
duplicates MDEV-25798 Windows SChannel clients fail to conn... Closed
Relates
relates to CONC-639 Unable to connect to SSL using client... Stalled

 Description   

The MariaDB connector on Windows seems unable to connect to a MariaDB server running on Ubuntu. Although the error (coming from MS Secure Channel) suggests a cipher mismatch, inspection of the ciphers supported on both sides shows 14 ciphers in common, one of which was selected by the server in the Server Hello.

The MySQL connector/C connects fine from Windows to the same MariaDB.

Inspection of the packets using Wireshark did not show an obvious problem. The Client Hello and Server Hello seemed ok (to a non-TLS expert). Stepping through the MariaDB Connector code on the Windows side also didn't show any obvious problem.

I've reached the limits of the debugging that I can do in this context. Are there other errors which MS will put into the "SEC_E_ALGORITHM_MISMATCH" return code? Are there any other known problems with MariaDB Connector/C on Windows? Any other ideas?

Wireshark files and (example self-signed) certificates are available.

To replicate:
(1) Have MariaDB 10.5.8 running on Ubuntu 20.04
In the config file have three lines
ssl-ca=/path/to/rootCA2.crt
ssl-cert=/path/to/sqlserver2.crt
ssl-key=/path/to/sqlserver2.key
add new user as
CREATE USER 'testuser'@'%' IDENTIFIED BY 'ChangeMe' REQUIRE X509;

(2) On Windows, use the command
"C:\Program Files\MariaDB 10.5\bin\mysql.exe" --ssl-cert=C:\Path\to\sqlclient2.crt --ssl-ca=C:\Path\to\rootCA2.crt --ssl-key=C:\Path\to\sqlclient2.key --user=testuser -pChangeMe --host=<ubuntu_hostname> --protocol=tcp --port=3306 --default-character-set=utf8

This should give the error
ERROR 2026 (HY000): SSL connection error: no cipher match. Error 0x80090331(SEC_E_ALGORITHM_MISMATCH)

Apologies if there is anything wrong with these settings, but I feel I have tried as many permutations as I can think of.

Thanks.

 Comments   
Comment by Georg Richter [ 2021-02-20 ]

Question about 10.5.8 server: Which tls library and version does the server use (show variables like 'version_ssl_library' will give you this information)?

Comment by Marco Paland [ 2021-03-23 ]

I don't want to hijack this issue, but I have a very similar problem, except that I get:

SSL connection error: An unknown error occurred while processing the certificate. Error 0x80090327(SEC_E_CERT_UNKNOWN)

I'm trying to SSL connect to a 10.5.9 mariadb binary package on debian buster, which is using WolfSSL 4.6.0 internally.

My client is Windows 10 and I tested it with the native mariadb c connector 3.1.11 and did another test with the latest HeidiSQL client - same error.

Generation of the used certs was done on the db server and is pretty basic.
Verifying gives:

openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OK

Do you have any advice, cause connecting via SSL is really mandatory for the app.

Comment by Georg Richter [ 2021-03-24 ]

Marco, this is different. If you think this is a bug, please file a new issue.

Comment by Vladislav Vaintroub [ 2021-06-01 ]

Note, that the error does not happen if one just tries to use SSL without the client certificate. It seems like there is something in the client certificate that server requires, and (according to schannel) client does not have. Also since there were no complaints about other Ubuntu versions, I'd expect something is off with openssl configuration on 20.04.

Comment by Vladislav Vaintroub [ 2021-09-25 ]

Please note also, that according to pcap file, the server sends CertificateRequest which includes 20 signature hash algorithms, but none of them matches SHA256 RSA,which is what client certificate has. 

 
 
Frame 9: 2563 bytes on wire (20504 bits), 2563 bytes captured (20504 bits)
 
Ethernet II, Src: Microsof_86:a3:61 (00:15:5d:86:a3:61), Dst: Microsof_fc:6b:a8 (00:15:5d:fc:6b:a8)
 
Internet Protocol Version 4, Src: 172.24.147.163, Dst: 172.24.144.1
 
Transmission Control Protocol, Src Port: 3306, Dst Port: 58323, Seq: 114, Ack: 227, Len: 2509
 
Transport Layer Security
 
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
 
    TLSv1.2 Record Layer: Handshake Protocol: Certificate
 
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
 
    TLSv1.2 Record Layer: Handshake Protocol: Certificate Request
 
        Content Type: Handshake (22)
 
        Version: TLS 1.2 (0x0303)
 
        Length: 52
 
        Handshake Protocol: Certificate Request
 
            Handshake Type: Certificate Request (13)
 
            Length: 48
 
            Certificate types count: 3
 
            Certificate types (3 types)
 
                Certificate type: RSA Sign (1)
 
                Certificate type: DSS Sign (2)
 
                Certificate type: ECDSA Sign (64)
 
            Signature Hash Algorithms Length: 40
 
            Signature Hash Algorithms (20 algorithms)
 
                Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
 
                Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
 
                Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
 
                Signature Algorithm: ed25519 (0x0807)
 
                Signature Algorithm: ed448 (0x0808)
 
                Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
 
                Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
 
                Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
 
                Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
 
                Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
 
                Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
 
                Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
 
                Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
 
                Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
 
                Signature Algorithm: SHA224 ECDSA (0x0303)
 
                Signature Algorithm: SHA224 RSA (0x0301)
 
                Signature Algorithm: SHA224 DSA (0x0302)
 
                Signature Algorithm: SHA256 DSA (0x0402)
 
                Signature Algorithm: SHA384 DSA (0x0502)
 
                Signature Algorithm: SHA512 DSA (0x0602)
 
            Distinguished Names Length: 0
 
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done

That's client certificate

The server only accepts SHA224 RSA, of all "sha rsa" signature algorithms family, but not SHA256 RSA.

Comment by Vladislav Vaintroub [ 2021-09-27 ]

There appears to be some kind of bug in openssl. According to google, Ubuntu made the decision to compile with non-default settings for openssl, to make it appear more secure.
https://github.com/Ensembl/ensembl-rest/issues/427 discusses one bug, but I'm not sure we're tripping over it. It looks like openssl itself is more lax about the strict requirements it imposes on client certificates, with SECLEVEL=2, than other SSL implementations are.

The workaround

Now, for all people who deal with that problem Ubuntu 20.04, this is one workaround

  • use parameter ssl-cipher=DEFAULT:@SECLEVEL=1 for the server, or
  • change /etc/ssl/openssl.cnf to add CipherString = DEFAULT:@SECLEVEL=1

There are some variations on CipherString workaround, a popular discussion in https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level.

This has something with the client certificate, and how it was created, but I frankly have no idea what that exactly can be.

Generated at Thu Feb 08 03:05:57 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.