Certificates requested through acme.sh are not issued as ISRG Root X1

Help
1

I requested a new certificate for a domain, and it did not come down signed as ISRG Root X1. I discovered the -preferred-chain after I first requested this. This cert shows up in browsers as not trusted.

I have tried pulling a new cert with --issue --force with --preferred-chain "ISRG Root X1", but it still does not come back signed ISRG Root X1.

When looking at the cert that does not work in the browser certificate viewer, I just see my domain name in the hierarchy in the cert that doesn't work. Other Let's Encrypt certs that work have ISRG Root X1 -> Let's Encrypt -> domain name in the hierarchy. It's like the cert was not signed with the CA. Am I reading that right?

This non-working cert shows the issuer as: CN = R11 / O = Let's Encrypt / C = US
Another cert that I have that works on a different device shows: CN = ISRG Root X1 / O = Internet Security Research Group / C = US

I am using acme.sh 3.1.0

Any suggestions?

Thanks in advance!

2

No, your certificate is fine (R10 and R11 are valid issuers and they chain to ISRG Root X1) but you may not be serving the correct chain, we can't tell without knowing your domain to check.

You mentioned a browser but don't tell us which one, different ones do different things, you also didn't tell us which web server you are using. I'm sensing that your site might be a secret?

Try not to use --force because that renews certs that don't yet need to be renewed.

5 Likes
3

Domain is henninger.net.

I was looking at it in Chrome. Web server is Nginx. This is a private server.

If you view the server external right now, it is on Apache. That is not the server I am working with.

4

I don't see anything listening on port 443 with HTTPS from the public Internet. So I am not sure what you mean by Apache was working there.

I do see that you've got three RSA certificates Signed by either R10 or R11 which is expected. Those intermediates in turn are signed by X1. This is normal.

On your private network can you show the output of this
openssl s_client -connect (domain):(port)

Use the appropriate domain you use on your private network or its local IP address. And the port you typically use. I assume 443

Cert history recent
https://tools.letsdebug.net/cert-search?m=domain&q=henninger.net&d=168

6 Likes
5

Please show:
openssl s_client -connect henninger.net:443 -showcerts

4 Likes
6

Nor do I (11:31 AM Thursday, October 10, 2024 )

curl -I http://henninger.net/
HTTP/1.1 500 Internal Server Error
Date: Thu, 10 Oct 2024 18:30:14 GMT
Server: Apache/2.2.22 (Fedora)
Connection: close
Content-Type: text/html; charset=iso-8859-1
2 Likes
7

I really appreciate everyone's help...

Do I need to install the ca.cer somewhere on this machine? In the example below, I tried to use the fullchain.cer as my cert.

Here is what I see with the openssl command:

CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R11
verify error:num=2:unable to get issuer certificate
issuer= C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Certificate chain
 0 s:/CN=henninger.net
   i:/C=US/O=Let's Encrypt/CN=R11
 1 s:/C=US/O=Let's Encrypt/CN=R11
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF/jCCBOagAwIBAgISA64HU+fYr6q8/LVrnwRdZPMjMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTEwHhcNMjQxMDEwMDI0NTQzWhcNMjUwMTA4MDI0NTQyWjAYMRYwFAYDVQQD
Ew1oZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
0qimLo5YGQfPff4h8Um9aW39HRoehRgCIrdrHEG6oZzWT7BWLgCBAk5qG7KMfLAK
owdyVRJ7t6SQhu5hy7QCB4Y0HvNSOWZ6owq9dzLM8WaMzpdrIhhlMp8GjvATUjkq
3Zekwg2IAq5TP0qfDDFSc4+VNqHvg49jlN1Z1QlVugJs0iBVjTooRV4uOxn/sou7
/KKHnbnJxMcqSfpGZG7dFd8W6Y7Gelzj0+rB9CqFQbWosQszhYrOXM0HJm0pAo19
UIKkL2ggOOs/uLXsuutRuKMCcZtOiwrCnaQogHe9BXDFc+DKMaMIkOHnYzKJklak
64RvNZpB+cbaZ0lEK/fjF7xUw3vOLDDNX2xgciGtX0wDksq/zm3XnLEGoUvbGnbj
6gRanB2ANXynmgz2Q9ykv6wzHk6lrREPVjRhFYHcXwrdXfo6grBrWbqnJPOkdRnX
3sMT4WNoK1a7cr8L1Ptf0nnZtqVL+C5lh19pEItxWnAOWzzQ7SJI+Yp+lzpQwHjW
aZmxA66mYHNijCMVL1TrZDwDKi+KHFtgmm92a6O7KYPnHp9TwtxeDeoyKnIQFc+U
icSUO90krdbhREY2x0Xz/rQ83BUS1KCJ6ivZDB0IaKiXOJVNUkpLAk42jHM1c8kG
uONUGiAuGMQyR4+Jbs593qqKY6ib2Ty3CtGujWcEPwkCAwEAAaOCAiUwggIhMA4G
A1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYD
VR0TAQH/BAIwADAdBgNVHQ4EFgQUkZhri3dFXai+5XyyvvqOnZThYRAwHwYDVR0j
BBgwFoAUxc9GpOr0w8B6bJXELbBeki8m47kwVwYIKwYBBQUHAQEESzBJMCIGCCsG
AQUFBzABhhZodHRwOi8vcjExLm8ubGVuY3Iub3JnMCMGCCsGAQUFBzAChhdodHRw
Oi8vcjExLmkubGVuY3Iub3JnLzArBgNVHREEJDAigg1oZW5uaW5nZXIubmV0ghF3
d3cuaGVubmluZ2VyLm5ldDATBgNVHSAEDDAKMAgGBmeBDAECATCCAQUGCisGAQQB
1nkCBAIEgfYEgfMA8QB2AOCSs/wMHcjnaDYf3mG5lk0KUngZinLWcsSwTaVtb1QE
AAABknSG8GcAAAQDAEcwRQIgKAv2aO6L34BbLsCCCcMVwZ14k6jfH4AAMs2Wy5uM
E94CIQDDlbuEQJfX9CamVtWHoJmbskO8WQX/6tDFbgltU+8BewB3AKLjCuRF772t
m3447Udnd1PXgluElNcrXhssxLlQpEfnAAABknSG9uYAAAQDAEgwRgIhANmsMQ29
qBBiGC4sRYBEokG2rLt6i5VTZUU2uEtJsOKvAiEA5uYbaxBl1XKRJ6x+jsyneXDk
+woD4HKUCG9iqNQ/VFswDQYJKoZIhvcNAQELBQADggEBAKGPDmbYZICLgIjWRi9L
Xx7lVN705Y6vQf5jZ2z98ZStNbuZUJGQFoEm5QUG3ybB8YYGIFeqWiLtiLgc3kuP
7kx84j6W+3/RRwTJs74JR3tsgGv4zQu8QIcTUEh5x4R2c0TAHwy5Jk6xGKDdWajl
covZ6D3VvS8oop+ozqmVFGOUxdAxLT68UffVUovfJpPat5MW5RyCwzy0girD/paA
C80rxcPjc2Z+313cDxPevUs//29XI1lt4AcgqqKx+psu2K5doQg9jj7gK3oQa6GW
e01qaizAYHVuCnwa94iVlNlBTk5kGCyRjjj/T1YA3Lzbeyzy6jfu1PCQ2LWkER2o
QQQ=
-----END CERTIFICATE-----
subject=/CN=henninger.net
issuer=/C=US/O=Let's Encrypt/CN=R11
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3762 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 33ABFF657DA6EFF9ABE0E0C47DD37590EA71F66E635D7AC3A5C22363DB3171E2
    Session-ID-ctx: 
    Master-Key: 1CAB8E550F7622CCF6F4C017F4F9487BAB3A7BA28EBCE1D6EABBE5068F0760C3B3B8B898B9A67650ACBDC137FFA2090F
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 86 b9 e2 96 b2 9a fb cf-8d 08 9e a5 35 09 9f 4d   ............5..M
    0010 - c4 20 1f 4b 6a 33 2e 2f-dd 4a 0d 89 2c 77 88 c2   . .Kj3./.J..,w..
    0020 - 35 4b 37 33 47 72 c5 25-d4 9f ba 0d 2c 13 21 82   5K73Gr.%....,.!.
    0030 - d1 00 63 1a 50 94 99 58-4e f1 84 ed 6d f2 6b c1   ..c.P..XN...m.k.
    0040 - 74 2a e6 62 bb 91 fe f2-cf 3d 9a 20 42 15 df ea   t*.b.....=. B...
    0050 - ca c0 3c a2 64 95 2f 14-2c b0 47 03 2a 2a 02 2f   ..<.d./.,.G.**./
    0060 - 36 29 e8 5f 97 a9 a0 5e-1d f2 fa e2 fa cc 59 1c   6)._...^......Y.
    0070 - 10 f9 22 41 74 bc 9e 4c-82 a9 3d 2c c8 53 ec 56   .."At..L..=,.S.V
    0080 - 44 d0 9c 5f fc fe ec b4-93 8f 74 86 c4 87 a9 8d   D.._......t.....
    0090 - 7f 82 80 7d 63 0c 19 ed-30 41 33 ca b5 a8 00 c6   ...}c...0A3.....
    00a0 - dd e9 e9 c6 c3 04 c2 61-9f 60 79 9a 15 cd ea 44   .......a.`y....D

    Start Time: 1728603578
    Timeout   : 300 (sec)
    Verify return code: 2 (unable to get issuer certificate)
---
closed
8

That is pretty normal apart from the failure to validate

But, it looks like your system does not have the ISRG Root X1 cert in its CA root store.

What kind of system did you issue that command on? Please give the operating system and version. Also any unusual items that might apply (custom builds and so on).

3 Likes
9

I think your system is only serving the leaf cert:

image
image407×515 9.27 KB

It should also be serving the intermediate cert [R11].

Please show the apache server host file (or section) that serves this name.

1 Like
10

It does:

1 Like
11

The -showcerts didn't show that cert...

2 Likes
12

They may have used my earlier suggested format. We need to know more about their system.

If they didn't send out the intermediate then how did openssl find it? Do you think they added it manually to their CA store?

Between this fullchain and the openssl chain display I think the most likely reason for failure is a very out of date CA Store. Or even a damaged store.

4 Likes
13 
PORT    STATE    SERVICE
22/tcp  filtered ssh
80/tcp  open     http
443/tcp filtered https

There may be other things going on here but this would likely cause issues.
But no cert is being served regardless of:

Which clearly shows current certificates.
But what does this mean?

I'm mostly blind.
But I see:

curl -I http://henninger.net/
HTTP/1.1 200 OK
Date: Sat, 12 Oct 2024 00:16:29 GMT
Server: Apache/2.4.37 (centos)
X-Powered-By: PHP/7.2.24

The https version is filtered. (blocked)
I shall be corrected I am sure.

2 Likes
14

I really appreciate everyone's help so far on this. As I mentioned earlier in my thread, the server that I am working with is not the server that is exposed to the Internet.

I am working on the advice that was given to check my CA store. I am working on that now.

Thank you all!

3 Likes
15

Can you:

  • use the server that is exposed to get the cert and then copy it to your other server?
  • proxy the incoming HTTP challenge requests to the server that needs the cert?
2 Likes
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.