Files
haproxy/docker
bitdeals ea8d5e0589
Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 21s
fix: pin the base by digest, and stop overriding its FIPS preference
The public door closed again this morning. haproxy exited at parse time on
every host with

    'bind *:443' : inconsistencies between private key and certificate
    loaded '/usr/local/etc/haproxy/certificates/site.pem'

on a leaf and a private key that openssl confirms are one pair — same public
key, and the same pair certbot has been serving since 2026-08-22. Nothing of
ours had changed: the image was rebuilt at 10:21 by the scheduled build, on a
base that had moved overnight.

The cause is the override this file added two days ago. Measured on testnet2,
same image, same certificate, only the variable changed:

    OPENSSL_FIPS=no    config check fails at `bind *:443`
    OPENSSL_FIPS=yes   config check passes, curl 200, TLSv1.3

`ENV OPENSSL_FIPS=no` was right for the 2026-09-02 base, where preferring the
FIPS provider left haproxy offering an X25519MLKEM768 group it could not use
and refusing every modern client. On today's base the same value stops it
loading an ECDSA certificate at all, while the shipped "yes" both loads it and
still negotiates TLS 1.3 — the thing the override existed to protect. So it is
removed rather than inverted; the comment keeps why, because the right value
depends on the base and the next base may want the other one.

Which is the second change, and the one that matters. `FROM bitnami/haproxy`
carries no tag and the build runs daily, so this image took whatever the base
was each morning: two outages in three days, neither with a commit behind it,
both diagnosed from scratch. The base is pinned by digest now — the one
measured working today. It stops moving on its own, and bumping it becomes a
deliberate act with a check behind it.
2026-09-04 11:30:32 +00:00
..