I've get cert with old date when trying to renew it

Help
1

Certbot return about certificate is successfuly update, but expire date stil old.
My domain is:
bitrix.rtc.kz
I ran this command:
certbot
It produced this output:
An unexpected error occurred:
There were too many requests of a given type :: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: bitrix.rtc.kz, retry after 2024-07-18T19:01:09Z: see Duplicate Certificate Limit - Let's Encrypt

My web server is (include version):
nginx version: nginx/1.24.0
The operating system my web server runs on is (include version):
CentOS Linux release 7.9.2009 (Core)
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 1.11.0

2

This is usually caused either by either:

  • the web server needs to be restarted to pick up the new certificate
  • your browser is using the cached old certificate

Checking your site your cert definitely expired over a year ago so check your nginx config points to the current certificate files. I assume you have restarted some time in the last year or so.

3 Likes
3

Are you sure the error is about an "old date"?

Because your current cert is one from the Let's Encrypt Staging system. These are good for testing but will not validate in browsers or other clients.

Also, check your system date/time

This is the cert I see now

openssl s_client -connect bitrix.rtc.kz:443

subject=CN = bitrix.rtc.kz
issuer=C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Counterfeit Cashew R10
notBefore=Jul 17 10:06:54 2024 GMT
notAfter=Oct 15 10:06:53 2024 GMT
3 Likes
4

Also when you checked with certbot certificates? Because Let's Encrypt would not issue expired certificates. It stands to reason the problem would be elsewhere, so keep requesting certificates from Let's Encrypt is useless.. And lead you to the current rate limit. Which is probably fine, as you already have the certificate issued.

1 Like
5

Yes, this is information about the test certificate that I managed to obtain today. I am attaching a screenshot of the previous certificates that I received at the beginning of the week. It seems that now I have managed to find the cause of this error. Please remove the limit for requesting a certificate for this domain.

image
image1161×726 113 KB

6

That is really strange. What does this show?

sudo certbot certificates

Also please show contents of this file

/etc/letsencrypt/renewal/bitrix.rtc.kz.conf
2 Likes
7

In this file you can find proof of my screenshot.
letsencrypt.log.26.txt (35.5 KB)

I think this error occurred because the Bitrix server menu also uses certbot and when Bitrix tried to request a certificate, it used it incorrectly.

I have removed /etc/letsencrypt/renewal/bitrix.rtc.kz.conf because this file was empty and this file was reason of error. Can you remove limit ban for my domain?

8

One thing in that log hints at the problem. Can you show output of this:

sudo ls -lR /etc/letsencrypt/{live,archive}

It looks like somehow the symlinks in the .../live/... folder were damaged. Probably replaced by an actual file(s). And, likely the very stale file.

Certbot is writing the new cert files to the .../archive/... folder as it should but the symlink isn't being created / updated because of the damaged symlinks.

From your log

CertStorageError: expected /etc/letsencrypt/live/bitrix.rtc.kz-0001/cert.pem to be a symlink
...
2024-07-15 07:40:06,888:DEBUG:certbot._internal.storage:Writing new private key to /etc/letsencrypt/archive/bitrix.rtc.kz/privkey2.pem.
2024-07-15 07:40:06,888:DEBUG:certbot._internal.storage:Writing certificate to /etc/letsencrypt/archive/bitrix.rtc.kz/cert2.pem.
2024-07-15 07:40:06,888:DEBUG:certbot._internal.storage:Writing chain to /etc/letsencrypt/archive/bitrix.rtc.kz/chain2.pem.
2024-07-15 07:40:06,888:DEBUG:certbot._internal.storage:Writing full chain to /etc/letsencrypt/archive/bitrix.rtc.kz/fullchain2.pem.

No, it is not possible. But, there may be work-around and we can use Staging system if need more tests. We can possibly recover the symlinks to use the existing certs in .../archive/...

2 Likes
9

In output you can find domain bitrixx.rtc.kz. Do not pay attention to it, it was created additionally so that the site can work while the problem with the certificate for the main domain is resolved.

[root@srv-bitrix v.zyulin]# sudo ls -lR /etc/letsencrypt/{live,archive}
/etc/letsencrypt/archive:
total 0
drwxr-xr-x 2 nginx nginx 217 Jul 17 10:24 bitrix.rtc.kz
drwxr-xr-x 2 nginx nginx 83 Jul 17 11:05 bitrix.rtc.kz-0001
drwxr-xr-x 2 root root 83 Jul 17 11:06 bitrix.rtc.kz-0002
drwxr-xr-x 2 nginx nginx 83 Jul 17 10:42 bitrixx.rtc.kz

/etc/letsencrypt/archive/bitrix.rtc.kz:
total 48
-rwxr-xr-x 1 nginx nginx 1838 Jul 17 10:24 cert1.pem
-rwxr-xr-x 1 nginx nginx 1765 Jul 17 10:24 cert2.pem
-rwxr-xr-x 1 nginx nginx 1842 Jul 17 10:24 cert3.pem
-rwxr-xr-x 1 nginx nginx 1826 Jul 17 10:24 chain1.pem
-rwxr-xr-x 1 nginx nginx 1801 Jul 17 10:24 chain2.pem
-rwxr-xr-x 1 nginx nginx 3749 Jul 17 10:24 chain3.pem
-rwxr-xr-x 1 nginx nginx 3664 Jul 17 10:24 fullchain1.pem
-rwxr-xr-x 1 nginx nginx 3566 Jul 17 10:24 fullchain2.pem
-rwxr-xr-x 1 nginx nginx 5591 Jul 17 10:24 fullchain3.pem
-rwxr-xr-x 1 nginx nginx 1704 Jul 17 10:24 privkey1.pem
-rwxr-xr-x 1 nginx nginx 1704 Jul 17 10:24 privkey3.pem

/etc/letsencrypt/archive/bitrix.rtc.kz-0001:
total 20
-rwxr-xr-x 1 nginx nginx 1838 Jul 17 11:05 cert1.pem
-rwxr-xr-x 1 nginx nginx 3749 Jul 17 11:05 chain1.pem
-rwxr-xr-x 1 nginx nginx 5587 Jul 17 11:05 fullchain1.pem
-rwxr-xr-x 1 nginx nginx 1708 Jul 17 11:05 privkey1.pem

/etc/letsencrypt/archive/bitrix.rtc.kz-0002:
total 16
-rw-r--r-- 1 root root 1830 Jul 17 11:06 cert1.pem
-rw-r--r-- 1 root root 1899 Jul 17 11:06 chain1.pem
-rw-r--r-- 1 root root 3729 Jul 17 11:06 fullchain1.pem
-rw------- 1 root root 1704 Jul 17 11:06 privkey1.pem

/etc/letsencrypt/archive/bitrixx.rtc.kz:
total 16
-rw-r--r-- 1 nginx nginx 1769 Jul 17 10:42 cert1.pem
-rw-r--r-- 1 nginx nginx 1801 Jul 17 10:42 chain1.pem
-rw-r--r-- 1 nginx nginx 3570 Jul 17 10:42 fullchain1.pem
-rw------- 1 nginx nginx 1708 Jul 17 10:42 privkey1.pem

/etc/letsencrypt/live:
total 4
drwxr-xr-x 2 nginx nginx 111 Jul 17 10:22 bitrix.rtc.kz
drwxr-xr-x 2 root root 93 Jul 17 11:06 bitrix.rtc.kz-0002
drwxr-xr-x 2 nginx nginx 93 Jul 17 10:22 bitrix.rtc.kz.old
drwxr-xr-x 2 root root 93 Jul 17 10:42 bitrixx.rtc.kz
-rwxr-xr-x 1 nginx nginx 740 Jul 17 10:22 README

/etc/letsencrypt/live/bitrix.rtc.kz:
total 8
lrwxrwxrwx 1 nginx nginx 42 Jul 17 10:22 cert.pem -> ../../archive/bitrix.rtc.kz-0001/cert1.pem
lrwxrwxrwx 1 nginx nginx 43 Jul 17 10:22 chain.pem -> ../../archive/bitrix.rtc.kz-0001/chain1.pem
lrwxrwxrwx 1 nginx nginx 47 Jul 17 10:22 fullchain.pem -> ../../archive/bitrix.rtc.kz-0001/fullchain1.pem
-rwxr-xr-x 1 nginx nginx 13 Jul 17 10:22 index.html
lrwxrwxrwx 1 nginx nginx 45 Jul 17 10:22 privkey.pem -> ../../archive/bitrix.rtc.kz-0001/privkey1.pem
-rwxr-xr-x 1 nginx nginx 692 Jul 17 10:22 README

/etc/letsencrypt/live/bitrix.rtc.kz-0002:
total 4
lrwxrwxrwx 1 root root 42 Jul 17 11:06 cert.pem -> ../../archive/bitrix.rtc.kz-0002/cert1.pem
lrwxrwxrwx 1 root root 43 Jul 17 11:06 chain.pem -> ../../archive/bitrix.rtc.kz-0002/chain1.pem
lrwxrwxrwx 1 root root 47 Jul 17 11:06 fullchain.pem -> ../../archive/bitrix.rtc.kz-0002/fullchain1.pem
lrwxrwxrwx 1 root root 45 Jul 17 11:06 privkey.pem -> ../../archive/bitrix.rtc.kz-0002/privkey1.pem
-rw-r--r-- 1 root root 692 Jul 17 11:06 README

/etc/letsencrypt/live/bitrix.rtc.kz.old:
total 16
lrwxrwxrwx 1 nginx nginx 37 Jul 17 10:22 cert.pem -> ../../archive/bitrix.rtc.kz/cert3.pem
lrwxrwxrwx 1 nginx nginx 38 Jul 17 10:22 chain.pem -> ../../archive/bitrix.rtc.kz/chain3.pem
-rwxr-xr-x 1 nginx nginx 5591 Jul 17 10:22 fullchain.pem
-rwxr-xr-x 1 nginx nginx 1704 Jul 17 10:22 privkey.pem
-rwxr-xr-x 1 nginx nginx 692 Jul 17 10:22 README

/etc/letsencrypt/live/bitrixx.rtc.kz:
total 4
lrwxrwxrwx 1 root root 38 Jul 17 10:42 cert.pem -> ../../archive/bitrixx.rtc.kz/cert1.pem
lrwxrwxrwx 1 root root 39 Jul 17 10:42 chain.pem -> ../../archive/bitrixx.rtc.kz/chain1.pem
lrwxrwxrwx 1 root root 43 Jul 17 10:42 fullchain.pem -> ../../archive/bitrixx.rtc.kz/fullchain1.pem
lrwxrwxrwx 1 root root 41 Jul 17 10:42 privkey.pem -> ../../archive/bitrixx.rtc.kz/privkey1.pem
-rw-r--r-- 1 root root 692 Jul 17 10:42 README

date is today because I moved certs for my tests.

10

Your Certbot folders are badly damaged.

Your bitrix.rtc.kz live symlinks point to the oldest cert in its related archive. They should point to the most recent (the files ending in 3 not the ones ending in 1).
This probably explains the odd dates we see

Your bitrix.rtc.kz.old live folder is a mix of files and symlinks when they should be all symlinks. Whatever damaged that folder was probably the beginning of your problem. I doubt the files in this folder are still referenced

Before trying to repair these folders we should review your nginx config. Would you please upload output of this?

sudo nginx -T >nginx.txt

An uppercase T is essential. The nginx.txt file will be large

2 Likes
11

nginx.txt (31.3 KB)

12

Thanks. We can focus on just this (other settings omitted)

server {
    listen	443  http2 ssl;
    server_name bitrix.rtc.kz; # managed by Certbot
...
# CERTIFICATE ANSIBLE MANAGED BLOCK
    ssl_certificate /etc/letsencrypt/live/bitrix.rtc.kz-0002/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/bitrix.rtc.kz-0002/privkey.pem; # managed by Certbot
# CERTIFICATE ANSIBLE MANAGED BLOCK

This domain currently replies with a Staging cert. We could try to issue a production cert with this -0002 profile but you are Rate Limited for that domain.

So, another option is to find a current production cert on your system and then change nginx to use that one.

Can you show contents of this file? You should never disclose the privekey.pem but this cert is known publicly. I am just doing to decode it to see what it is. I am hoping it is a valid cert

/etc/letsencrypt/archive/bitrix.rtc.kz/cert3.pem
2 Likes
13

Сertificate:
Data:
Version: 3 (0x2)
Serial Number:
03:e2:1e:bc:5f:d5:42:50:c4:e8:89:52:a9:31:92:80:5c:6e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=R3
Validity
Not Before: Sep 22 04:07:20 2022 GMT
Not After : Dec 21 04:07:19 2022 GMT
Subject: CN=bitrix.rtc.kz
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:bd:a6:08:dd:d3:da:6b:20:fa:8f:92:41:b5:39:
57:fd:92:b4:20:80:4e:c6:fa:ed:f0:c0:92:cf:3f:
79:89:c9:ef:69:e1:56:c6:60:5d:85:d9:43:fc:74:
89:f9:7f:5d:2f:1f:8f:b6:c5:73:59:21:ee:f7:dc:
35:d1:68:7c:d2:cd:e8:5d:86:fd:78:5f:da:70:c6:
5d:3c:4e:32:7e:57:e7:35:06:69:7f:73:56:e6:77:
71:f0:5e:c9:62:0c:35:2c:6d:c9:f9:71:b6:64:85:
71:66:33:fd:a7:a5:fc:cb:b5:8c:ab:34:11:2e:fe:
c0:da:1f:0c:2c:16:8c:51:3a:99:09:06:77:da:c6:
b9:10:a7:18:2c:cf:47:41:43:01:1c:21:18:4c:bd:
5b:ac:86:53:f8:84:0b:f2:f0:73:e2:1a:8c:f0:e4:
69:f6:38:5d:33:87:de:1c:ab:bc:69:e7:7a:f5:a6:
6d:89:82:6b:f9:da:a5:21:71:da:51:11:ed:3a:54:
cf:53:b3:78:21:d0:d4:49:22:c1:21:d8:56:5c:b6:
3a:b2:61:8d:ed:0c:34:4a:df:5d:f1:09:bd:72:e2:
0c:79:ea:7c:e9:79:fa:f0:a2:75:6d:36:67:e4:5a:
5c:26:f8:a9:17:bd:75:1c:c5:37:45:f8:45:ae:e2:
26:4f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
D1:61:34:AE:9D:15:B2:F7:D6:97:88:2F:E3:1D:C4:3B:70:68:62:74
X509v3 Authority Key Identifier:
keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

        Authority Information Access:
            OCSP - URI:http://r3.o.lencr.org
            CA Issuers - URI:http://r3.i.lencr.org/

        X509v3 Subject Alternative Name:
            DNS:bitrix.rtc.kz
        X509v3 Certificate Policies:
            Policy: 2.23.140.1.2.1
            Policy: 1.3.6.1.4.1.44947.1.1.1
              CPS: http://cps.letsencrypt.org

        CT Precertificate SCTs:
            Signed Certificate Timestamp:
                Version   : v1(0)
                Log ID    : DF:A5:5E:AB:68:82:4F:1F:6C:AD:EE:B8:5F:4E:3E:5A:
                            EA:CD:A2:12:A4:6A:5E:8E:3B:12:C0:20:44:5C:2A:73
                Timestamp : Sep 22 05:07:20.842 2022 GMT
                Extensions: none
                Signature : ecdsa-with-SHA256
                            30:46:02:21:00:8B:9F:36:59:DB:09:04:1C:E6:65:18:
                            28:C3:0C:5E:DA:73:A0:24:5D:EF:93:E6:55:7C:D1:20:
                            01:F4:4C:BE:38:02:21:00:9C:68:F0:31:E9:56:85:5F:
                            EB:C5:8F:9C:93:8D:62:52:F0:F9:07:97:0D:97:79:E3:
                            9F:4F:6B:96:F3:D2:AC:97
            Signed Certificate Timestamp:
                Version   : v1(0)
                Log ID    : 29:79:BE:F0:9E:39:39:21:F0:56:73:9F:63:A5:77:E5:
                            BE:57:7D:9C:60:0A:F8:F9:4D:5D:26:5C:25:5D:C7:84
                Timestamp : Sep 22 05:07:20.834 2022 GMT
                Extensions: none
                Signature : ecdsa-with-SHA256
                            30:46:02:21:00:A9:72:7A:51:D1:16:F8:D2:86:FD:B5:
                            FE:F7:41:8A:96:31:6B:A1:68:92:59:FB:8F:B7:17:6B:
                            D5:42:9A:F7:F6:02:21:00:B8:5A:B5:E8:8D:CA:F7:8F:
                            F6:5F:3B:ED:2A:FC:74:A9:7D:BD:DD:E7:A5:3E:1A:48:
                            CF:5E:07:96:CA:40:8F:2B
Signature Algorithm: sha256WithRSAEncryption
     5b:da:37:20:47:d2:0b:01:92:6f:fc:1b:37:12:3a:21:92:bc:
     d8:53:79:df:34:68:d2:02:18:be:59:27:a4:62:0b:84:66:60:
     3a:8e:bc:3a:b0:d6:49:d0:2c:2f:cd:8a:a1:f2:22:03:e4:00:
     fa:fe:4f:d4:73:c8:c2:a4:0b:a2:71:4f:cf:a7:0b:34:c1:a0:
     00:b7:8b:67:b0:a1:c7:87:ab:9a:64:d6:5d:a1:7e:06:db:c9:
     b0:5b:a3:74:b3:d6:2a:64:b2:b4:87:79:17:a9:97:db:27:4f:
     ae:8c:37:89:c1:eb:cb:3a:b3:bb:ab:9b:6d:76:02:e1:42:77:
     64:9e:87:e4:56:93:d0:20:ea:af:65:24:49:3b:40:48:80:bc:
     48:a0:bb:78:fe:4f:e8:8f:ac:d9:57:dd:a8:ce:7a:5d:3a:8b:
     22:41:ad:77:e3:46:04:0e:b6:50:45:75:71:76:d7:1b:eb:0a:
     7d:6b:f6:3a:46:d3:5a:c3:71:38:45:79:70:66:5f:0c:cd:5a:
     c9:25:8c:4f:bd:46:76:35:72:10:1b:f9:0d:08:2d:18:de:9e:
     28:01:86:0c:6e:3a:27:60:6a:13:28:77:40:fa:59:c1:98:2f:
     c4:38:82:ca:78:a9:38:57:b2:ab:11:8f:cf:97:1f:3d:53:f9:
     cc:7a:f7:0c
14

Hmm, well that's no help. What about this one?

/etc/letsencrypt/archive/bitrix.rtc.kz-0001/cert1.pem

I mean, you have gotten a bunch of certs for that domain in the last couple days. They must be somewhere.

2 Likes
15

I'll let Mike continu debugging, but I'd like to address this part of an earlier post:

Rate limits cannot be reset or removed manually. Please be more careful and thoughtful in the future.

16

Please delete this folder [or move it out of the /etc/letsencrypt path]:

^ you should aways let certbot do the work for you.

2 Likes
18

Also, none of those should be owned by nginx.
It is likely the reason why certbot can't use them correctly.

2 Likes
19

Ty for ur help, I'll try to find requested certs in archive tomorrow.

2 Likes
20

it's a pity. ok, thanks for your help.

1 Like
21

As a result, it helped to delete .conf files, with zero weight, in the /etc/letsencrypt/renewal/ directory

Many thanks to everyone for their help in setting up and understanding how to use certbot correctly

2 Likes