And those are the only 3 files in that folder? If so, makes no sense to me how haproxy can be using such an old cert.
You should inspect your system to locate the file(s) related to that old cert. Then identify what is referencing those files. Those files must be somewhere being used by something on your system.
You might even look at the haproxy and apache access logs after making a request to the test subdomain. Make sure those requests show up in the servers they should be.
My servers are behind haproxy, so I let it handle the certs.
So, your concerns are:
getting cert(s) into haproxy
getting haproxy configured to proxy requests to your "proxy server (Ubuntu22LTS/nginx/LetsEncrypt)"
getting your "proxy server (Ubuntu22LTS/nginx/LetsEncrypt)" configured to proxy to the "existing webserver (Ubuntu22LTS/Nginx/PHP/Mysql/LetsEncrypt)"
No. My haproxy is handling certs just fine. And I am not using nginx.
I am using LXC containers. I have ports 80 and 443 on the host forwarding to my haproxy container. The haproxy forwards the sub-domain to the proper container. Works like a champ.
My concern is I have one website that is not using the correct cert. It is using the expired cert instead of the renewed cert. So let's trouble shoot why the expired cert is being used and not the renewed cert.
Let's not be concerned about the infrastructure (LXD containers) I am using. It works fine.
Make sense?
Thanks,
Ray
I don't know how we could help debug without understanding the infrastructure
Which component(s) terminate(s) TLS? And, what entity is reporting the expired cert?
For example, in a typical reverse proxy the proxy itself terminates HTTPS from client requests like a browser on the 'net (using a cert). The proxy server uses a second connection to the backend server and that can be HTTP or HTTPS. If HTTP you don't need a cert on that backend at all. If HTTPS you need a cert on that backend server which satisfies whatever the proxy needs for that connection. You could possibly even use a long-lived self-signed cert.
These are the kinds of things we are trying to clarify. Without knowing specifics about what is failing it is hard to give specific advice. Trying to give general advice is impractical because there are so many ways to do things.
So, is the fact I can https into www.streamingworld,us not really a secure connection, as the browser is indicating?
@rayj00 Are you the same person as @Heetered who started this thread?
Because there is another thread that you started
No, I'm not heetered.
Unless your comments are intended to help heetered please post on your own thread.
NOTE: Moved all the posts from the other topic to this one.
How do I determine what files are associated with the old cert?
Maybe look for files ending in '.pem' ? If you used other naming conventions check those. Learn about using a 'find' command and check any volume / folder they might be. It must be somewhere for your system to be using it.
From sudo find / -name *.pem -print: There are literally thousands of .pem files on my haproxy server in the following folders:
/etc/letsencrypt/archive/
/etc/letsencrypt/csr/
/etc/letsencrypt/keys/
/etc/ssl/certs
/usr/lib/python3/dist-packages/twisted/
/etc/letsencrypt/live/test.streamingworld.us/fullchain.pem
/etc/letsencrypt/live/test.streamingworld.us/chain.pem
/etc/letsencrypt/live/test.streamingworld.us/privkey.pem
/etc/letsencrypt/live/test.streamingworld.us/cert.pem
The certs for my websites are in /etc/haproxy/certs/
root@HAProxy:/etc/letsencrypt# sudo find / -name test.streamingworld.us.pem -print
/etc/haproxy/certs/test.streamingworld.us.pem
find: ‘/sys/kernel/debug’: Permission denied
find: ‘/sys/fs/pstore’: Permission denied
find: ‘/sys/fs/fuse/connections/50’: Permission denied
find: ‘/dev/.lxd-mounts’: Permission denied
find: ‘/proc/sys/fs/binfmt_misc’: Permission denied
find: ‘/proc/tty/driver’: Permission denied
Since haproxy is terminating SSL/TLS, how is the security propagated to the browser when haproxy forwards the request to the website?
What other info do I need to supply?
A user-agent (like a browser) makes an HTTPS request to connect to your domain.
Your haproxy system sees this request. It looks in its config to find where the cert file is and uses the cert within it for the connection. There is no other place for the cert (and private key) to come from other than your own system.
For some reason your haproxy is using a cert that expired almost 2 years ago. There is really nothing more I can say about this. Your haproxy is either finding that very old cert in some place you don't know. Or, haproxy is not even handling the requests for test domain like it is for your others.
Maybe you have some network router or something that sends HTTPS (port 443) requests for test domain directly to your Apache server. I don't know. There are many ways to setup systems and you need to understand how yours is setup.
You may need to consult with a server and/or network expert or hope for an answer on the haproxy forum.
Problem solved! Apparently there was an expired cert in the haproxy /etc/haproxy/certs folder that was being used for the failing website.
I don't understand how haproxy works. I thought there was a one for one cert for each website? Why haproxy looks at all of the certs is beyond me.
Thanks for any responses.
Ray
Huh. That's odd because when we asked for a directory list of that folder you showed there was only 3 files and all were recent.
We also described how haproxy resolved which cert to use back in posts 15 and 16. Of course, the haproxy docs describe this too 
My bad. Apparently a cut/paste mistake.
All is good now.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.