Cert Expired Renewed Cert Still Expired?

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: test.streamingworld.us

I ran this command: certbot certificates

It produced this output: Certificate Name: test.streamingworld.us
Domains: test.streamingworld.us
Expiry Date: 2024-05-27 20:30:36+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/test.streamingworld.us/fullchain.pem
Private Key Path: /etc/letsencrypt/live/test.streamingworld.us/privkey.pem

My web server is (include version):
Server version: Apache/2.4.41 (Ubuntu)
Server built: 2023-10-26T13:54:09

The operating system my web server runs on is (include version):
Ubuntu Server 22.04
My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.31.0

I use Haproxy to forward subdomains to LXD containers. It's been quite a while since I got back to working in this website. So I updated the cert as such:

$ certbot certonly --cert-name test.streamingworld.us -d test.streamingworld.us
$ cd /etc/letsencrypt/live/test.streamingworld.us
$ cat fullchain.pem privkey.pem > /etc/haproxy/certs/test.streamingworld.us.pem
$ service Haproxy restart

I have other LXD containers that I treat the same way and they work fine.

Note that I can proceed with the browsing in the un-secured mode (http).

SSLCheck results in: Stand by...
Processing https://test.streamingworld.us
Done.
No issues found.

But running Qualsys SSLlabs results in:
|Valid from |Sun, 26 Dec 2021 06:18:49 UTC| |---|---|
|Valid until |Sat, 26 Mar 2022 06:18:48 UTC (expired 1 year and 11 months ago) EXPIRED|

Ideas?

Thanks,

Ray

1 Like

Hello @rayj00, welcome to the Let's Encrypt community. :slightly_smiling_face:

Here is a list of issued certificates crt.sh | test.streamingworld.us, the latest being 2024-02-27.

However what is being served is this expired certificate crt.sh | 5864890177 as can be see from here https://decoder.link/sslchecker/test.streamingworld.us/443

So the certificate renewal happened correctly, it is just not being used.

Did you restart Apache?

3 Likes

It's very strange how haproxy is not serving the cert you provided.

2 Likes

Certbot should be updated Certbot 2.9.0 Release
Please see Certbot Instructions | Certbot

3 Likes

Yet they say Apache in the beginning

2 Likes

That web server is behind the haproxy.

3 Likes

Using certbot --version 0.31.0, I just renewed a different cert for a different website behind the same Haproxy and it works? I'm a little paranoid to update certbot. More ideas?

Ray

If you can export the haproxy config, I'd review that manually to ensure everything related to the failing domain is as expected [is same as other working domains are].

4 Likes

Yes I did restart Apache.

Here is the haproxy cfg file:

global
    log 127.0.0.1 syslog debug
    lua-load /etc/haproxy/cors.lua
    maxconn 2000
    tune.ssl.default-dh-param 2048
    user haproxy
    tune.maxrewrite     4096
    group haproxy

    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-bind-ciphers EECDH+AESGCM:EDH+AESGCM

defaults
    log global
    mode http
    option forwardfor
    option http-server-close
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    timeout tunnel  2h  #this is for websocket connections, 2 hours inactivity timeout
    timeout client-fin 5000
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http


frontend http_lb
  bind *:80
  bind *:443 ssl crt /etc/haproxy/certs/
  #redirect scheme https if !{ ssl_fc } # Added code 301
  http-request redirect scheme https unless { ssl_fc }

 acl testbox hdr(host) -i test.streamingworld.us

  acl acl_letsencrypt path_beg /.well-known/acme-challenge/
  use_backend be_letsencrypt if acl_letsencrypt

 use_backend testenv if testbox**

backend be_letsencrypt
        server letsencrypt 127.0.0.1:8888


 backend testenv**
 balance leastconn**
 http-request set-header X-Client-IP %[src]
 redirect scheme https if ! { ssl_fc }
 server testing  10.90.200.247:80 check verify none

Surely someone here would know how to troubleshoot this?

I am not sure what you are asking for help about but it seems you have a haproxy config problem. It looks like you got a Let's Encrypt cert just fine.

Have you tried asking on a haproxy support forum?

3 Likes

I renew an expired cert for a website and the cert is renewed successfully. However, when browsing to the site, it is using the expired cert! I restarted Apache2. No help.

Note that the website(s) is behind an Haproxy that I use to forward sub-domains located in LXD containers. This works fine for other sites. I am using the same process to renew the cert that I use on other sites that work fine.

And yes, I am asking this same thing on the Haproxy forrum.

Suggestions are welcome.

Thanks,

Ray

1 Like

I don't know haproxy well but shouldn't you specify the name of the merged cert you made rather than just the folder?

2 Likes

According to the HAProxy config tutorial documentation, yes, the path should end with the name of a pem file.

frontend www
  bind :443 ssl crt /certs/site.pem
  default_backend webservers
2 Likes

Thanks for doc link @linkp. Within that doc is below so a path is allowed. But, seems like haproxy is not selecting the right cert. Maybe using a full filename will help. Or, review all the certs in that folder to ensure there are no expired ones. My guess is there probably is one.

You can also set the crt argument to a directory. When set to a directory, the load balancer will use Server Name Indication (SNI) to search the directory for a certificate that has a Common Name (CN) or Subject Alternative Name (SAN) field that matches the requested domain, which the client sends during the TLS handshake.

2 Likes

Thanks for digging deeper into that. I suspected that may be possible. Based on the symptoms described, I endorse your theory that using a complete path, even if just for testing purposes, should remove ambiguity.

2 Likes

There is only one test.streamingworld.us.pem file in the haproxy cert folder.

I use the same basic haproxy config for all my websites with no issues. Here's how I renew a cert:

Within the haproxy container, I do:

certbot certonly --cert-name test.streamingworld.us -d test.streamingworld.us
cd /etc/letsencrypt/live/test.streamingworld.us
cat fullchain.pem privkey.pem > /etc/haproxy/certs/test.streamingworld.us.pem
restart haproxy

Here is a site that correctly uses a renewed cert. The website does nothing, but you can see SSL is working: https://www.streamingworld.us/

That is almost impossible. Where else would haproxy find a cert that expired almost 2 years ago? Unless haproxy is not really the one handling these requests - is that possible?

haproxy looks "inside" each cert file for that domain name. It does not go by file name. Are you sure there are no stray files in there?

What does this command show?

ls -lR /etc/haproxy/certs
2 Likes

There is one cert folder. Inside is a single .pem file for each subdomain it serves.

root@HAProxy:/etc/haproxy/certs# ls -lR /etc/haproxy/certs
/etc/haproxy/certs:
total 112
-rw-r--r-- 1 root root 5307 Feb 28 13:34 streamingworld.us.pem
-rw-r--r-- 1 root root 5315 Feb 27 21:31 test.streamingworld.us.pem
-rw-r--r-- 1 root root 5311 Feb 28 13:38 www.streamingworld.us.pem