curl error 77: certificate verify locations on a VPN install

You paste the installer one-liner from a tutorial, press Enter, and get curl: (77). The message mentions certificate verify locations, so the instinct is to assume the VPN provider's certificate is broken and reach for a flag that skips verification. That reading is wrong, and acting on it turns a local file problem into a security decision. Walk it back from the beginning.

Step 1: read what the number means

Error 77 is about the local CA input: curl could not read or load the certificate material it was told to trust. Error 60 is the one about the peer, where the server's chain does not validate. They appear next to each other in tutorials and mean opposite things.

If your output says 77, the server was never the problem. The client could not open the file it wanted to use for checking, which is a path, permission or packaging issue on your machine.

Step 2: read the command you copied

Copy-pasted commands hide characters. Lowercase -l is --list-only, which applies to listing protocols. Uppercase -L is --location, which follows an HTTP redirect. They are not alternate spellings, and a tutorial that writes one while describing the other sends people down a redirect path that was never intended.

Following a redirect does not repair a trust-store path, and it does not establish that the final host is the publisher you meant. If the command came from a forum post, retype it from the project's own instructions instead of trusting the paste.

Step 3: find which CA input that build uses

Start by identifying the binary, because the answer depends on how it was compiled:

curl --version

Record the version and the TLS backend. A build using a native trust store reads the system store through the TLS library, while a build pointed at a bundle reads a file. An explicit --cacert, a CURL_CA_BUNDLE setting or a shell wrapper can override either one, so a package install may not touch the file that is actually failing.

For a file-based store, check three things in order: does the path exist, can the invoking account read it, and does it contain the CA material you expect. A bundle with the wrong permissions fails identically to a missing one, and both fail before any network conversation about the server happens.

Step 4: repair the input, not the verification

Restore the supported trust configuration through whoever owns it: the distribution package, your configuration management, or the documented environment variable. The goal is a readable, correct CA input for that binary.

Do not switch the URL to HTTP, add --insecure, or trust a certificate copied from an unexplained download. Each of those changes what you are willing to accept instead of fixing what curl could not read, and the change tends to outlive the incident.

The curl error catalogue is the reference for the numbers, and it is short enough to read once properly.

Step 5: download, look, then execute

Retrieve the installer to a file rather than piping it into a shell in the same command. That single change separates a transfer you can inspect from code that runs with your privileges.

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

Check that the response is the script you expected and not an HTML error page, a redirect notice or an empty file. If the publisher provides a checksum or signature, verify it through their documented release process rather than a value quoted in the same forum thread.

Remember what HTTPS did and did not do. It authenticated the transport to the host you contacted; it did not review the script's contents, and it does not tell you whether the publisher is trustworthy.

Step 6: keep the install steps separate

Downloading the file, installing the client, configuring the tunnel and validating routes are four operations with four different failure modes. Doing them one at a time means an error later in the sequence has one obvious cause instead of four candidates.

If the install succeeds and the tunnel comes up, verify the routes and one real destination before you close the ticket. The curl error is fixed when a plain curl -I https://example.invalid works again, not when the installer stops complaining.