Support

Do remember that ghcr.io is operated by Microsoft, it's part of GitHub itself. We have no control over it, let alone its TLS certificates.

That said, something is definitely wrong with your machine. Please see https://www.ssllabs.com/ssltest/analyze.html?d=ghcr.io . As you see, the TLS certificate of ghcr.io is valid, signed by Sectigo, and expires in June 2025. Are you sure your machine is not simply missing the CA root cache?

SSL: no alternative certificate subject name matches target host name 'serviciosti1.xxx.xxx.ar'

Your problem is that the certificate does NOT match the hostname serviciosti1.xxx.xxx.ar. You cannot "accept" an invalid certificate.

Fix your site. Let's Encrypt certificates are FREE and have been free since 2014. There's no reason to have a live host with an invalid, self-signed, default, not-meant-for-production certificate anymore.

Cybersecurity enforcing bad TLS certificates which can only be used... by ignoring them? What else do they do at this company? Security doors with no locks? Fire extinguishers filled with gasoline?

Your problem is NOT that your certificate is self-signed. You can pass the expected certificate, or its signing authority's public certificate, with the --certificate parameter. There is a valid use case for this, and it's fully supported.

Let me explain this by first telling you how an internal, airgapped setup we actually do use for testing works. We use the hostname test.local.web. This hostname is mapped to 127.0.0.1 and ::1 using /etc/hosts on our Linux server. I have created our own CA, which signs an intermediate root, which signs the certificate for test.local.web. I pass the public key for the root CA in the --certificate parameter. The cURL library (what PHP actually uses to communicate with the web server) sees the self-signed certificate for test.local.web and confirms that a. its hostname matches the hostname cURL was asked to connect to and b. the certificate is validly signed by the intermediate CA which is validly signed by the root CA which is part of the certificate authority cache we told cURL to use (and which includes our custom certificate). There are many more checks performed (e.g. date checks, integrity checks etc), but these two are the ones which are pertinent to our discussion.

Your problem is that step in bold type: your TLS certificate's Common Name does not correspond to the hostname you are asking cURL to connect to. In simple terms, your TLS certificate claims to be for a different domain name.

But, why does cURL (and wget, and every other HTTPS library) do both of these checks? Why not just check if the TLS certificate is signed? Why check the Common Name at all? No, it's not a conspiracy to sell more certificates. To understand the reasoning we have to step back and talk about HTTPS.

The whole point of HTTP over TLS (HTTPS) is to prevent Man-In-The-Middle (MITM) attacks. HTTPS can help with that because the two ends – the client (you) and server (site) – can mutually authenticate each other over a tamper-evident protocol. The tamper-evident property is crucial. The lynchpin of the whole process is the server's TLS certificate. This lets the client verify that it's talking to the intended server and, as a result, trust the rest of the information exchange between them.

An evil attacker sitting between the client (you) and the server cannot break HTTPS without making it obvious; that's the tamper-evident property of the protocol. At best, the attacker in the middle would be establishing an HTTPS connection to the client, and a separate one to the server, relaying data between these two connections. But since the attacker is sitting at the end of each encrypted connection, they can record or manipulate this data. This would be obvious to the client because the TLS certificate used in the HTTPS connection to the man-in-the-middle would a. have a Common Name not matching the actual site we're connecting to and/or b. not have a valid signature from a Certification Authority the client trusts. As you may have noted, these are the two things checked by cURL and every other HTTPS library.

So, what does --no-check-certificates do?

In short, it removes both of these checks (plus the other checks I didn't include since they are irrelevant to our discussion). Since the library checks neither the Common Name, nor the signature of the certificate a MITM attacker would be able to operate undiscovered. In simple terms, this option breaks HTTPS, offering exactly ZERO security whatsoever, making the connection equivalent to plain old HTTP as far as MITM attacks go. The only "protection" it offers is against naive network packet scanning. Basically, it's this: Worst Security Security Check (tenor.com)

Why does wget offer this option?

wget is a generic tool. It has to support a lot more use cases than our software. There are many use cases where you want to establish whether the problem is the certificate or the server. Using this option you will know. If the connection is made with this option, the problem is the certificate. This is a great troubleshooting first step. It's certainly easier to use than openssl, which is the second step if the problem was found to indeed be the certificate.

Why are we not offering this option in our software?

Because there is no practical use case where it makes sense to do that instead of using plain old HTTP. If you have an issue with your certificate's signature (but the Common Name is correct) we do give you the --certificate option to work around it; that's a valid use case, as illustrated by our air-gapped test setup described above.

If, however, your certificate's Common Name does not even match your site's domain name you are in a situation where there is zero security, therefore you might just as well use plain old HTTP instead of HTTPS with ignoring certificate validity altogether! In both cases, the connection would be equally insecure. The only difference is that HTTPS with --no-check-certificates gives you an illusion of security (even though there is none to be found), whereas using HTTP will raise your heckles as you instinctively know it's insecure.

Now, about the organisation.

I find it hard to believe that the cybersecurity department would enforce using TLS certificates with the wrong Common Name. If they had even a junior sysadmin with a passing interest in security amongst them they'd immediately know that the only way to use this kind of TLS certificate is by ignoring it, which is worse than using plain old HTTP. If they are unaware of this fact, they need to be fired immediately.

Worse than providing no security, worse than providing a false sense of security, their enforced rule is a huge liability for the company they work in! There is no insurer in the world who will take a quick glance at this and pay out a cybersecurity insurance when (not if) they get hacked or ransomwared as this policy runs afoul of the contractual requirement to take preventative security measures. The same thing goes for any cybersecurity assessment. If they implemented this policy to tick the "Use HTTPS everywhere" box in a self-assessment cybersecurity form, then the company has committed perjury and the self-assessment is invalid! They are putting their company in huge financial and legal risk by being, not to put too fine a point on it, utterly incompetent.

As I said in the beginning of this reply, what they do is like having security doors without locks, or fire extinguishers filled with gasoline. Sure, the security theater is there, but there's no real security. It's more than certain that in case of an actual emergency the bad security practices would cause more harm than good.