Pure-Python TLS fingerprint check prints CryptographyDeprecationWarning on every connection to a zero-config TLS server (certificate serial 0)

Summary

MariaDB 11.4+ zero-configuration TLS generates a self-signed server certificate with serial number 00. The pure-Python client's fingerprint path parses that certificate with cryptography.x509.load_der_x509_certificate to check its validity dates (mariadb/impl/client/ssl/ssl_fingerprint_validator.py, around line 106). cryptography warns on a non-positive serial (RFC 5280 §4.1.2.2), and the warning is a UserWarning subclass, so Python shows it by default. Every process that connects prints it to stderr.

The mariadb command-line client (Connector/C 3.4 + OpenSSL) verifies the same certificate over TLSv1.3 with no warning. Connector/Python 1.1.14 on Connector/C 3.4.10 (ssl=True, ssl_verify_cert=True) also verifies it cleanly.

Reproduction

import mariadb

c = mariadb.connect(host="mariadb", user="toolkit", password="...", database="fleet")

.../mariadb/impl/client/ssl/ssl_fingerprint_validator.py:106: CryptographyDeprecationWarning: Parsed a serial number which wasn't positive (i.e., it was negative or zero), which is disallowed by RFC 5280. Loading this certificate will cause an exception in a future release of cryptography.

  cert = x509.load_der_x509_certificate(self.cert_der)

Server certificate, from openssl s_client -connect mariadb:3306 -starttls mysql | openssl x509 -noout -serial -subject:

serial=00

subject=CN = MariaDB Server

Impact

• Any CLI built on the connector prints the warning on every run, mixed into stderr with its own messages. Users (and coding agents) tend to silence warnings globally to get rid of it, which hides real ones.
• The warning says a future cryptography release will raise instead. The validator's except Exception: return None would then silently skip the validity-date check on every zero-config server.

Suggested fix

1. Parse inside warnings.catch_warnings() with CryptographyDeprecationWarning ignored, or read the validity dates without the full X.509 parse, so the date check keeps working once cryptography turns the warning into an error.
2. Server side (separate MDEV): generate the zero-config certificate with a positive random serial, as RFC 5280 requires.

Reference: https://mariadb.org/mission-impossible-zero-configuration-ssl/