[aborah-sudo]

The cert was CN=master.ldap.test with no subjectAltName, so StartTLS to the master2.ldap.test alias failed hostname verification under ldap_tls_reqcert = demand.

gen-certs.sh now builds a per-service SAN list, each certificate getting its own hostname plus any aliases. Only master.ldap.test.crt is regenerated, re-signed with the existing CA and key; a full run would also replace the CA and break running containers until every image is rebuilt.

[jakub-vavra-cz]

LGTM.

[justin-stephenson]

My only concern is if updating data/certs/master.ldap.test.crt will break something, it looks like certificates in data/certs/ directory have not been updated in 4 years.

[aborah-sudo]

My only concern is if updating data/certs/master.ldap.test.crt will break something, it looks like certificates in data/certs/ directory have not been updated in 4 years.

Fair question, I worried about the same thing, so I deliberately kept the blast radius as small as possible.

The CA is untouched. That was the main design decision here. Running gen-certs.sh in full would regenerate ca.crt and all three service certs, and ca.crt is referenced in twelve places (trust-ca.sh, client/enroll_IPA.yml, ad, keycloak keystore, common, samba, ipa, ldap, tmt/setup.sh, actions/setup). Replacing it would invalidate every trust store until all images were rebuilt. So instead of running the script over data/certs, I re-signed only the LDAP certificate using the existing CA and its existing key. The diff is two files, and data/certs/ca.crt, dc.samba.test.crt and master.keycloak.test.crt are all unchanged.

The LDAP cert has exactly one consumer. src/ansible/roles/ldap/tasks/main.yml:27, at image build time. Nothing else in the repo reads it, so only ci-ldap is affected.

The new certificate is a strict superset of the old one:

• same private key, openssl x509 -pubkey and openssl pkey -pubout hash identically, so anything keyed on it is unaffected
• same subject, CN=master.ldap.test, so clients that match on CN behave exactly as before
• openssl verify -CAfile data/certs/ca.crt passes against the unchanged CA
• the four original extensions are preserved, subjectAltName is simply added

The only behavioural change is in the direction of working more often, not less: previously a client that requires SAN and ignores CN (which is what RFC 6125 and most modern TLS stacks do) had nothing to match against.

Verified against a live server, by importing the new cert into the running ldap container with the same dsctl tls import-server-key-cert the ansible role uses:

X509v3 Subject Alternative Name:
    DNS:master.ldap.test, DNS:master2.ldap.test

$ openssl s_client -starttls ldap -verify_hostname master.ldap.test ...
Verify return code: 0 (ok)

and the failover suite, which runs over StartTLS with ldap_tls_reqcert = demand throughout:

15 passed in 90.33s

On the four years point, I read that as the certs simply not having needed a change, rather than them being fragile. The old one was valid until 2041 and the new one until 2046, both issued by the same CA.

One thing worth stating plainly: this has no effect until ci-ldap is rebuilt and published, since the certificate is baked into the image. My verification above imported it into a running container, which is a faithful preview but not the real build, so an image refresh is the honest final confirmation.