Report each server certificate against the config that loaded it

[madolson]

tls_server_cert_serial reports whichever certificate OpenSSL gave the lower slot index, not the one in tls-cert-file. Slot order is by key algorithm, so with an RSA and an ECDSA certificate configured, swapping the two config values produces identical INFO output. Anyone alerting on tls_server_cert_expires_in_seconds silently starts watching a different file the moment they add an alt certificate. This captures each certificate's serial and expiry while the context is being built, which is the last point where the file it came from is known, and carries those with the context.

Based on valkey-io/valkey#3717 head 0e36225, so the base branch here is pr3717-alt-cert-base.

Details

Problem

tlsRefreshServerCertInfo walks the cursor with SSL_CERT_SET_FIRST then SSL_CERT_SET_NEXT and assigns the results to the primary and alt fields in that order (src/tls.c:401-417). OpenSSL orders slots by algorithm, not configuration order:

/* openssl-3.5 ssl/ssl_cert.c:390 */
int ssl_cert_set_current(CERT *c, long op)
{
    if (op == SSL_CERT_SET_FIRST)
        idx = 0;
    ...
    for (i = idx; i < c->ssl_pkey_num; i++) {
        CERT_PKEY *cpk = c->pkeys + i;
        if (cpk->x509 && cpk->privatekey) {
            c->key = cpk;
            return 1;

SSL_PKEY_RSA is 0 (ssl/ssl_local.h:319).

config	before	after
cert=EC, alt=RSA	RSA / EC	EC / RSA
cert=RSA, alt=EC	RSA / EC	RSA / EC
cert=ML-DSA, alt=RSA	RSA / ML-DSA	ML-DSA / RSA
cert=EC, no alt	EC / none	EC / none

Two configs, byte-identical output:

### tls-cert-file=valkey-ec.crt   tls-alt-cert-file=valkey.crt
    tls_server_cert_serial:5D4D62F058073EEFF4EE8CBB2298B81525011451
    tls_server_alt_cert_serial:5D4D62F058073EEFF4EE8CBB2298B81525011453
### tls-cert-file=valkey.crt      tls-alt-cert-file=valkey-ec.crt
    tls_server_cert_serial:5D4D62F058073EEFF4EE8CBB2298B81525011451
    tls_server_alt_cert_serial:5D4D62F058073EEFF4EE8CBB2298B81525011453

Not RSA-specific. Ed25519 (slot 7) with ECDSA (slot 3) and no RSA anywhere still reports the EC certificate as primary in both orders. Single-certificate configs report correctly, which is why this is quiet.

Fix

createSSLContext loads each certificate with its key and records the serial and expiry of whichever certificate that key activated, into a tlsServerCertInfo that travels with the context through both the synchronous and background reload paths. The refresh publishes those. Nothing has to identify a slot afterwards.

Alternatives considered

Read the configured PEM at refresh time to recover its key algorithm, then find the matching slot. Much less plumbing. It loses because it makes INFO follow the file on disk rather than the loaded certificate, and tls-auto-reload-interval defaults to 0 while applyTLSPort (src/config.c:2939) calls tlsResetCertInfo() without rebuilding the context, so the two diverge indefinitely. Deleting tls-cert-file and then setting tls-port reported tls_server_cert_serial:none for a certificate still being served.

Record the key algorithm at load time and use that as the slot key. This is what the first version of this PR did, and it is wrong for the case the feature exists for. EVP_PKEY_base_id goes through the legacy pkey->type, which is -1 for a provider-only key, so it returns NID_undef for ML-DSA. ssl_cert_lookup_by_pkey matches by name via EVP_PKEY_is_a and has a second loop over provider-registered sigalgs (ssl/ssl_cert.c:1325), so the certificate resolves to a slot and loads fine. Result on OpenSSL 3.6.2 with the stock default provider:

$ valkey-server --tls-cert-file mldsa.crt --tls-key-file mldsa.key
tls_server_cert_serial:none
$ echo | openssl s_client -connect 127.0.0.1:33560
subject=O=Valkey Test, CN=MLDSA-cert
Peer signature type: mldsa44

Read the two files outright with tlsUpdateCertInfoFromFile(), the way tlsRefreshCACertInfo() does for CA certificates. Loses for the same reason as the first alternative.

Certificate cursor

Base reset the current certificate to the lowest slot at the end of every refresh. The refresh no longer walks the cursor, so createSSLContext resets it instead, leaving outgoing TLS 1.2 connections picking the same client certificate they picked before. No behaviour change, and no test: it covers pre-existing behaviour, so it belongs with the fix for it rather than here.

Not fixed here

A certificate whose private key does not match it still loads, because OpenSSL routes a key to the slot for its own algorithm and only checks it against whatever certificate is already there. tls_server_cert_serial then names a certificate the server cannot present. 0e36225 got that case wrong too, naming the alternate's certificate instead, and unstable already starts with a mismatched pair and completes no handshake at all. Separate bug, separate change.

Two provider-only certificates, ML-DSA-44 with ML-DSA-65, are rejected as "the same key algorithm" because EVP_PKEY_base_id is NID_undef for both. Pre-existing in #3717 and untouched here.

Testing

The mapping test pins each serial to the file that configured it, using the single-certificate case to establish which serial is which. Asserting only that the two serials differ, or that they swap, passes while the mapping is inverted.

Fails on 0e36225 with only src/tls.c reverted:

[err]: TLS: INFO reports each certificate against the config that loaded it in tests/unit/tls.tcl
Expected '5D4D62F058073EEFF4EE8CBB2298B81525011453' to be equal to '5D4D62F058073EEFF4EE8CBB2298B81525011451'

The reload test covers the background path, which the mapping test does not reach. Deleting the swap in tlsApplyPendingReload leaves the mapping test green and fails only this one.

ML-DSA is verified by hand, not in the suite: utils/gen-test-certs.sh no longer generates a PQC certificate as of 0e36225.

This was generated by AI but verified, with love, by a human.