Use certificate with nonroot program

Honestly, not sure if my problem is permissions or what.

I have a program I'm running that people can connect to. When I disable SSL in the programs options it works fine. If I enable SSL no one can connect to it. I obtained certificates using this command: sudo certbot certonly --email \ --webroot --webroot-path /usr/local/share/webapps/letsencrypt/ \ -d
I point the program to those certificates in its config file like this:

So not sure why connections to server don't work with SSL enabled.

My domain is: .......... which redirects to my IP

I ran this command: namei -l /etc/letsencrypt/archive/

It produced this output:

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

My hosting provider, if applicable, is: Netlify

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

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

Are ports 54330 and 54331 open in your firewall? I can't connect to either port: just timeouts.


Looks like they are to me

I might be blind, but I'm just seeing ports 54001, 54002, 54230, 54231 and port 80? Not 54300 nor 54331?

1 Like

Dude you have eyes. Apparently I dont


Unfortunately, it seems the software you're using (which software is it anyway?) doesn't handle the fullchain.pem the correct way: it only uses the top certificate (which is the end leaf certificate) and ignores the intermediate certificate(s). This can and probably will lead to errors in the clients connecting to the service.

However, I'm not sure how the software you're using (again, no idea which software it is..) can be configured to use the intermediate certificate(s).

1 Like

Well it works now. I feel silly but whatever it works. Was just a port issue. I changed a bunch of permissions for my user to access the certs. Not sure if that was necessary now or not. You're the second person to tell me it doesn't use intermediate certificates. So not sure what that means exactly.

User certificates nowadays are never directly signed by the root certificates which are present in browsers or other clients and are trusted by those browsers/clients. There is one (or more) certificate(s) between the root certificate and the user certificated, called intermediate certificate(s). If the server doesn't send the intermediate certificate used to sign the user certificate, clients can have a hard time building a so called "chain" of certificates to one of the trusted root certificates. If they can't build a trusted chain, the user certificate will be judged as un-trusted.

You can see the certificates used by Let's Encrypt here:

Note that fullchain.pem embeds all the required intermediate certificates. But for some reason the software you're using doesn't use the intermediates in that file.

1 Like

I hate to point out the somewhat obvious (or do I?).
But did you read (and understand) lines 70-73 ?
It might be exactly how to resolve this lack of chain problem.

1 Like

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