Where can I find the Intermediate certificate

Help
1

Hello together,

first, I am a newbe in certificates and such themes.
So I have created a lets encrypt certificate with the steps from Let’s Encrypt Zertifikat erstellen mit Certbot auf Windows | Techys-Web
The certificate check from my partner says, certificate is okay but the Intermediate certificate is incomplete:

Certificate Chain Complete?
Your certificate could not be chained to a valid, trusted CA root, likely due to missing or invalid Intermediate certificate(s). This may result in errors displayed for your site by some browsers.

How can I find the missing certificate? Thanks for a short hint.

Kind Regards
Marco

1 Like
2

The intermediary certificate resides here: /etc/letsencrypt/live/<yourdomain>/chain.pem.

It would be great to know in which application you use the certificate. One common mistake is to use a cert.pem file (which doesn't include the intermediaries) instead of a fullchain.pem (which does), though it depends on the expectations of the app.

3 Likes
3

Thank you for the very quick response. I have assigned the fullchaim3.pem, which contains 3 certificate blocks but the check result is the same.

I dont know, which application our partner uses. Only the information, that a java procedure checks the certificate and the system will not continue to connect, if the cert check fails.

Do you have another idea?

4

If this partnerʼs system works “on behalf” of your domain name, could they not get the certificates themselves? Other than that, the files that I described should be enough.

Perhaps someone else on this forum can assist further. They may ask for the information below, which shouldʼve been presented when creating a new topic in a Help category.

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. https://crt.sh/?q=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:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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

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

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

4 Likes
5

I will describe the environment. We have a static ip. The partner system must connect to this ip, but the connection must be secure. So I have booked a domain and I created the certificate with the steps from the link from my first post by txt record. After that i modified the A-record to point to our IP.

The created certificate was added to our erp system. It is closed source, i can only add the keyfile, the certificate and certificates passwort. My erp system says only "SSL Settings successful". There are no more informations available.

Our partner told me, that the certificate is not complete. So I begun the search for solutions and found this community.

Because of this special situation I do not filled out the question template. Ash to my head.

My domain is:
rbauto.info

I ran this command:
n/a

It produced this output:
n/a

My web server is (include version):
no web server, it is a service included in our erp

The operating system my web server runs on is (include version):
The erp runs on a Windows server.

My hosting provider, if applicable, is:
n/a

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

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

1 Like
6

Thank you, your description makes things much clearer!

Visiting your domain, Iʼm greeted with a self-signed certificate and a login prompt by some, I would presume, firewall appliance? Is this to be expected?

I see a couple of options:

  1. Check whether your ERP system has an ACME capability. If not: pester the ERP developer to add native ACME capabilities.
  2. Setup a reverse proxy like Caddy, nginx or Apache (among others)[1] in front of your ERP system and terminate TLS on it.

I suggest these options because if you were to find and fix the chain issue, you would have to manually issue and install the certificates every 2-3 months, which is… sub-optimal, donʼt you agree?

  1. Though there may be a more Windows friendly option, but Iʼm not familiar with this part of Windows world too much, perhaps, once again, someone else will suggest a better alternative… ↩︎

3 Likes
7

Nekit, you need to connect to port 9229. Sorry, I forgot!

8

Shouldʼve figured. Yes, indeed I see a LE certificate and indeed no intermediaries:

$ openssl s_client -connect rbauto.info:9229 </dev/null
[…]
---
Certificate chain
 0 s:CN = rbauto.info
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 11 04:30:36 2023 GMT; NotAfter: Aug  9 04:30:35 2023 GMT
---
[…]

I would probably double check whether pkcs12 file has more than one certificate:

$ openssl pkcs12 -nokeys -in /path/to/.pfx

If it does — then the issue is in the ERP system. May it be that the intermediary certificates should be supplied separately? Perhaps contact the documentation/support of your system with this question.

The options in my previous post still stand.

3 Likes
9

That sounds like a problem in the making.

4 Likes
10

The Chain of Trust - Let's Encrypt has all the Root and Intermediate Certificates.

3 Likes
11

Thanks @all.

Because of a new workstation I have created the certificate again. Now is it valid until September.
After creation I testet the certificate with the openssl command from Nekits post. Openssl show three blocks, so I think, the Intermediate certificate is included:

  1. issuer=C = US, O = Let's Encrypt, CN = R3
  2. issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
  3. issuer=O = Digital Signature Trust Co., CN = DST Root CA X3

If so, so is a problem with the erp web service possible. I contacted our partner and ask him, if there any other customers with the same erp system live or not. Maybe we are the first one with all the problems.

This certificate I have inserted in our erp system and the check shows the new date but also the warning of the missing Intermediate certificate. I use to check Check SSL Certificate

3 Likes
12

Hello together,

there is no solution from the partner or the ERP support available. Only the information, that another unnamed customer with the same ERP is active since some days.
Thats sounds, the problem is not in the ERP. But I can not contact him because missing contact data.
Can anyone confirm, that my check with Openssl is okay. If so, why shows the ssl check an error?

--
Certificate Chain Complete?

Your certificate could not be chained to a valid, trusted CA root, likely due to missing or invalid Intermediate certificate(s). This may result in errors displayed for your site by some browsers. Learn how to repair intermediate certificate errors.
Illo certificate
**Common Name:**rbauto.info
Organization:
Valid: June 23, 2023 to September 21, 2023
Issuer: R3

13

Not for whatever service is listening on port 9229. That service only sends the end leaf certificate.

6 Likes
14

By default the certificate chain used by certbot for Let's Encrypt will be to the expired DST Root CA X3 root,

I think you need to set your preferred chain to ISRG Root X1 with --preferred-chain that way the full chain will stop at R3 and if ISRG Root X1 is in your systems trust store then the server will be able to build the path of [Your Cert] > R3 > ISRG Root X1

2 Likes
15

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