Hi all, I’m facing this weird behaviour so I report you for further investigation. I’m using haproxy 1.6.5
I’m trying to automate X.509 certificate replacement of haproxy frontends while they expires, so I wrote a script that simply generate the new PEM and issue a reload to haproxy. Reload command the script give is haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) now the weird thing: it seems that haproxy is somehow caching the old certificate: this is what happens if I connect from another host: (I used 2 different certificates to make it evident: the old one was *.itc4u.ch, the new one is apache-2.prod.itc4u.local - but I suppose this should happen even when replacing an expiring certificate with a new one) openssl s_client -connect apache-2.prod.itc4u.local:443 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA verify return:1 depth=0 C = CH, ST = TI, L = Pregassona, O = ITC4u Sagl, CN = *.itc4u.ch after a few executions openssl s_client -connect apache-2.prod.itc4u.local:443 CONNECTED(00000003) depth=1 O = ITC4U.LOCAL, CN = Certificate Authority verify return:1 depth=0 O = ITC4U.LOCAL, CN = apache-2.prod.itc4u.local and after other executions again openssl s_client -connect apache-2.prod.itc4u.local:443 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA verify return:1 depth=0 C = CH, ST = TI, L = Pregassona, O = ITC4u Sagl, CN = *.itc4u.ch this seems to be randomly happening The more weird thing is that it seems to happen even if I stop haproxy and start it again As I’m using a clustered environment (but it is an active/hot standby), e even checked haproxy log files and each time I receive a reply from the same cluster node (that actually is the only active one) I get it logged, so I’m absolutely sure replies always comes from the same node In order to ensure that is not something related to openssl s_client, I tried with firefox, and got exactly the same behaviour Kind regards Marco Carcano
