CODEWITHSUNDEEP
ssl-certificatehaproxylets-encrypt
carla
carla

Reputation: 2117

Haproxy wont recognize new certificate

I recently changed my certificate to LetsEncrypt's.

I placed the new certificate in the location of the old one:

cat /etc/haproxy/certs/fullchain.pem /etc/haproxy/certs/privkey.pem > /etc/haproxy/certs/mydomain.com.pem

And in my haproxy.cfg I have:

frontend https
bind :::8443 v4v6 ssl crt /etc/haproxy/certs/mydomain.com.pem no-sslv3

Then I ran systemctl reload haproxy, but it still brings the old one when I access it in my browser or using SSLLabs.

If I use curl -kv mydomain.com it shows the correct certificate.

Upvotes: 5

Views: 7583

Answers (4)

hassanzadeh.sd
hassanzadeh.sd

Reputation: 3501

First of all you have to stop haproxy service :

sudo service haproxy stop

after that, kill all processes related to HAProxy :

ps aux | grep haproxy
user_1     3648060  0.0  0.0  ...
user_root  3680653  0.0  0.0  ...

kill all processes:

kill -9 <process id>
kill -9 3648060
kill -9 3680653

finally, restart HAProxy service and watch logs :

sudo service haproxy start
tail -f /var/log/haproxy.log

Upvotes: 0

Chaitanya Kadian
Chaitanya Kadian

Reputation: 51

I had this same issue where even after reloading the config, haproxy would randomly serve old certs. After looking around for many days the issue was that "reload" operation created a new process without killing the old one. The old processes were serving the outdated certs. You can check this by "ps aux | grep haproxy".

Fix

If your environment allows for a few seconds of downtime run "service haproxy stop" until no haproxy processes are left and then start haproxy.

                                       **OR**

Sort by starting time and kill old processes while checking if the service is still running in between.

1 Year later EDIT

Instead of manually doing the fix mentioned above after every reload, we added a "hard-stop-after" for 600 seconds. Made sure to kill all old processes after adding the param and checked the same using ps aux. So now, older processes have to die after 600 seconds, and cannot serve outdated certs.

Upvotes: 4

Ain Tohvri
Ain Tohvri

Reputation: 3035

My problem was historic and outdated wildcard cert that HAProxy (HA-Proxy version 1.8.19-1+deb10u3 2020/08/01) erroneously picked up and spitted out as outdated subdomain cert, both in the browser and in cURL.

Reloading, restarting, stopping+starting and even upgrading Debian did not help. What did help was to remove the outdated wildcard cert and reload.

Upvotes: 0

Vladimir Mijatovic
Vladimir Mijatovic

Reputation: 21

If you have the old pem file in /etc/haproxy/certs, HAproxy might be using it instead of new one.

I had a similar problem. HAproxy was using expired certificate that was first created for only dev.domain.com with Let's Encrypt. Later I changed certificate creation process to include multiple domains: domain.dom www.domain.com and dev.domain.com. The old dev.domain.com.pem was still in /etc/haproxy/certs folder. When I visited https://dev.domain.com, HAproxy used old pem certificate file and Chrome issued a warning for expired certificate. When I deleted dev.domain.com.pem file and reloaded HAproxy, it started using new certificate and SSL is working correctly again.

Upvotes: 2

Related Questions