Curl can't verify SSL certificate, but browser can

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. crt.sh | 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: https://pterodactyl.trixyservers.com

I ran this command: curl https://pterodactyl.trixyservers.com:8443

It produced this output:
curl: (60) SSL: no alternative certificate subject name matches target host name 'pterodactyl.trixyservers.com'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

My web server is (include version): Apache 2.4.38

The operating system my web server runs on is (include version): Deepin 20.2 (based on Debian)

My hosting provider, if applicable, is: ionos.com is my domain provider, if that's what this means

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, unless pterodactyl counts

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

2 Likes

The certificate returned is only valid for node1.trixyservers.com. You should install the proper certificate for the proper virtualhost.

2 Likes

More specifically, just in case it wasn't clear from the circumstances and what Osiris wrote:

You have a server on port 443 serving https://pterodactyl.trixyservers.com/ and that's fine and it has a certificate which proves it is pterodactyl.trixyservers.com however on port 8443 you've got another server (likely an Apache virtual host) which presents instead this certificate for node1.trixyservers.com

Maybe the situation is that the port 8443 service is only intended to be named node1.trixyservers.com, in which case things are more or less working and you just need to call it node1.trixyservers.com to get things working as you expected. e.g. curl https://node1.trixyservers.com:8443/

Or maybe the situation is that you need different Apache virtual host settings to get what you wanted. We can't tell from here.

2 Likes

Everything is running on the same system, and each domain has a cert, and one of my programs can't verify the certificate either, so it can't run and I have no idea how to fix it

1 Like

Forgive me if I sound a little ignorant, but I think I get what you mean

Still confused though

1 Like

So "curl https://pterodactyl.trixyservers.com" works, but adding :8443 doesn't work, and https://node1.trixyservers.com:8443 doesn't work at all, also, even though i have ssl certs set up for all 3 sites, only pterodactyl.trixyservers.com has ssl? im so confused

1 Like

Welcome to the Let's Encrypt Community :slightly_smiling_face:

I'll try to help make things clearer.

You can use the following to track what certs have been issued for trixyservers.com:

https://crt.sh/

In your apache configuration, you need to look at the VirtualHosts defined in your configuration files. Specifically you need to look at which ServerName and (maybe) ServerAlias is/are defined within each VirtualHost along with which SSL certificate and key is defined within that VirtualHost. You're pairing the host (ServerName/ServerAlias) with the certificate and its key. Be aware of the port number associated with each VirtualHost (something like *:443).

You should begin by identifying which configuration files are active with:

sudo apachectl -S

You can use the following to identify which certificates you have available:

sudo certbot certificates

That command will help you match the certificate names to a part of the directory listed next to the SSL certificate and key directives in your apache VirtualHosts. This will let you know what domain names are covered by each named certificate and the path to the appropriate fullchain and privkey files for that certificate.

Everything looks valid to me, but still only one of the sites seems to have SSL despite the others being set up correctly (all by certbot). Is it because I'm running it on only one apache server?

bump because I still haven't fixed the problem

Can you share the output of sudo apachectl -S?

1 Like

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443 is a NameVirtualHost
default server www.trixyservers.com (/etc/apache2/sites-enabled/main-le-ssl.conf:2)
port 443 namevhost www.trixyservers.com (/etc/apache2/sites-enabled/main-le-ssl.conf:2)
port 443 namevhost node1.trixyservers.com (/etc/apache2/sites-enabled/node1-le-ssl.conf:2)
port 443 namevhost pterodactyl.trixyservers.com (/etc/apache2/sites-enabled/pterodactyl-le-ssl.conf:2)
*:80 is a NameVirtualHost
default server www.trixyservers.com (/etc/apache2/sites-enabled/main.conf:1)
port 80 namevhost www.trixyservers.com (/etc/apache2/sites-enabled/main.conf:1)
port 80 namevhost node1.trixyservers.com (/etc/apache2/sites-enabled/node1.conf:1)
port 80 namevhost pterodactyl.trixyservers.com (/etc/apache2/sites-enabled/pterodactyl.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

looks like 8443 isn't served by apache at all, lets see sudo netstat -tulpn | grep 8443 so we can see which process using that port
btw did you turn the server off? I can't connect to your website at all

1 Like

Server is up now, and that command outputs nothing

The port 8443 service doesn't seem to be up right now, at least from where I'm checking!

1 Like

the port 8443 service is up now, but pterodactyl.trixyservers.com still can't connect to the daemon running on node1.trixyservers.com:8443

it looks like it still uses certificate that only name is node1.trixyservers.com,
that The required authorization heads were not present in the request reply is Nodejs itself refuse to talk as we are not authenticated, to not sure what's your problem now

1 Like

If your app talks to node1.trixyservers.com:8443 then the cert it has on that port looks fine, if your app tries to talk to pterodactyl.trixyservers.com:8443 instead then that probably won't work because the name in the subject of the certificate is wrong. You could just use the cert you already have for pterodactyl.trixyservers.com:443 - the same cert can be used for multiple services.

1 Like

Really? How would I do that?

My best suggestion would be to look at your existing server configuration files to see how you are pointing to the certificate files, then update that.

You will gain a lot by have a proper read through all of your configuration files for your web services, so that you understand it more, especially regarding where your certificates are being kept and how to point configuration to different files.

Relying on tools to set all the values means you don't get the experience/knowledge required to really understand how it all works. We could keep going back and forth here trying to help you configure this but I don't think it's actually helping you.

2 Likes

First step IMHO is for you to actually understand which software is running on your system and which software is providing what exactly. I mean no offence, but I have a feeling you don't fully grasp the workings of your own system, which is pretty much a requirement for us to successfully help you with this specific issue.

1 Like