How do I tell if I have the Long or Short Chain?

And can Fullchain be modified to correct if necessary?

To answer your topic title: you could use OpenSSL to see the actual chain send by the server by e.g. running:

openssl s_client -connect yourhostname:443

Yes.

4 Likes

I don't think I made myself clear. I only have access to the client.

root@beaglebone:~# openssl s_client -connect us-east-va.sip.flowroute.com:5061
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = us-east-va.sip.flowroute.com
verify return:1
---
Certificate chain
 0 s:CN = us-east-va.sip.flowroute.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---root@beaglebone:~# openssl s_client -connect us-east-va.sip.flowroute.com:5061
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = us-east-va.sip.flowroute.com
verify return:1
---
Certificate chain
 0 s:CN = us-east-va.sip.flowroute.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---

Note that I have added the self-signed ISRG_Root_X1 [it was missing] and updated DST_Root_CA_X3 to the non-expired one on my client. Still getting "expired certificate" when my client tries to connect.

You either send the cross-signed ISRG Root X1 or you don't send X1 at all. Don't send the self-signed X1, the client has it, and it won't work if it doesn't have it anyway.

There is no unexpired DST Root X3.

5 Likes

Those two things contradict each other.

4 Likes

Here is a reference on Long (default) and Short (alternate) Certificate Chains Explained

4 Likes

So I should delete the certificate from the root store? {this certificate stuff is all kinds of confusing}

Please be specific.
Which certificate and from which root store?

3 Likes

Problem solved - I think. The chain wasn't the problem. I was listing the Private key file in the [client] tls conf file and the server was puking on it. Removed the entry for "priv_key_file" and it is working again/

ISRG_Root_X1 - this is the client. I have no access to the server

How old is the client?
[ISRG_Root_X1 cert is more than 7 years old - it should have already been there]

3 Likes

A brand new 16.28 install on Debian 10 with OpenSSL 1.1.1n. I'm pretty sure it was the cross signed one.

How would you have access to the private key then?

2 Likes

When Certbot runs it creates files privkey1.pem, etc. That is what I'm trying to figure out. Do I ignore them completely???

Why would you run Certbot on a client? I'm very, very confused right now.

And how would you be able to get a certificate (and corresponding private key) if you don't have access to the server? For what hostname did you create that certificate on the client?

4 Likes

This post by @jsha should help on concept of Chains in general to help you understand the why and what Chains do and not do for you.

1 Like

My point exactly... Let me back up a little. We're mixing apples & oranges a bit here, unavoidably. I'm runnning a voip server and I want to make a tls connection to a proxy. For one-way [calling out] only.

  1. This makes me a tls client by definition.
  2. Lets Encrypt tells me I need to run/use Certbot in order to utilize tls. So I run Certbot.
  3. One of the Lets Encrypt engineers {I think it was} indicated that the proxy "us-east-va.sip.flowroute.com" requests to "verify client". So I'm trying to prove that verification is being done.
  4. The Asterisk documentation/Wiki/forum has not proven to be extremely helpful in configuring my server. I have pieced together enough information to get rid of the error that I was getting but recently made a wild stab... Maybe Certbot is not needed at all? But how do I be sure the "client verify" is being done?

Hope this helps.

1 Like

Not quite accurate, Certbot is only a suggestion from here Getting Started - Let's Encrypt
There plenty of other ACME v2 Clients to choose from, here: ACME Client Implementations - Let's Encrypt

1 Like

Where would LE tell you that, if you're a TLS client?

Where did the LE engineers tell you that? Also, if we're talking about client authentication using TLS certificates, that's usually very different than server verification and usually doesn't use certificates from public CAs such as LE.

The sysops of the proxy where you're connecting to that requires this client authentication. I.e., sysops of us-east-va.sip.flowroute.com I guess.

3 Likes

@hraycrum69 are you referring to

1 Like