Fix curl SSL connect error on macOS with self-signed certs

The error you're seeing

You run curl https://your-internal-server and get back:

curl: (35) SSL connect error

This almost always means curl can't trust the certificate your server sent. With self-signed certs, that's expected—your Mac doesn't know who issued it. The fix depends on how permanent you need it.

I've seen this on macOS Big Sur, Monterey, Ventura, and Sonoma. It's especially common with internal dev servers, Docker containers, or test environments where you generated your own SSL cert.

Fix 1: The 30-second bypass (--insecure)

This is the quickest way to confirm the server is reachable. It tells curl to skip certificate validation entirely. Don't use this in production scripts, but for a quick test it's fine.

1. Open Terminal
2. Run: curl --insecure https://your-server-address

What you should expect: If the server is up, you'll get the response body instead of the SSL error. If you still see error 35, the problem isn't the cert—it's something else like a firewall or wrong port.

Short version: curl -k https://your-server does the same thing. The -k flag is just shorter.

Fix 2: The 5-minute per-request fix (specify the cert)

If you need to verify the server's identity but don't want to permanently trust the cert, you can point curl to the self-signed certificate file for that one request.

1. Get the self-signed certificate file from your server (usually a .pem or .crt file). If you don't have it, ask your admin or generate one.
2. Save it somewhere accessible, like ~/Downloads/server.crt
3. Run: curl --cacert ~/Downloads/server.crt https://your-server-address

What you should expect: Curl will use that certificate to validate the SSL handshake. If the cert matches the server's, it'll connect fine. If it doesn't match (wrong CN or expired), you'll get a different error like SSL certificate problem: self signed certificate in certificate chain. In that case, the cert file itself is bad.

This fix works great for occasional use. If you're hitting the same server daily, it gets old typing the --cacert path each time.

Fix 3: The permanent 15-minute fix (add to macOS keychain)

This is the real fix. You add your self-signed certificate to the macOS Keychain as a trusted root. After this, every curl command (and Safari, Chrome, etc.) will trust that server's cert.

1. Get the server's certificate file in .pem or .crt format. If it's a .pem file, open it in TextEdit and make sure it starts with -----BEGIN CERTIFICATE-----
2. Open Keychain Access (Cmd+Space, type "Keychain Access")
3. Click the "System" keychain on the left sidebar, then click the "Certificates" category at the bottom
4. Drag your .pem or .crt file into the certificate list. You'll see it appear with a red icon—that means it's not trusted yet.
5. Double-click the certificate you just added
6. Expand the "Trust" section by clicking the arrow next to it
7. Change "When using this certificate" from "Use System Defaults" to "Always Trust"
8. Close the window. You'll be prompted for your Mac password to save changes

What you should expect: After step 7, the red icon should turn blue. Now run curl https://your-server-address without any flags. It should work. If it doesn't, try restarting your terminal or running sudo killall -HUP mDNSResponder to flush DNS cache (rarely needed but worth a shot).

One gotcha: if your self-signed cert has an IP address as its Common Name (CN) instead of a domain name, macOS may still refuse it. That's a limitation of Apple's certificate validation, not curl's. In that case, use the --insecure flag or generate a cert with a proper domain name.

What to do if nothing works

If you've tried all three and still get error 35, the problem might not be the certificate at all. Here's a quick checklist:

• Is the server actually listening on that port? Try telnet your-server 443 (or whatever port). If it hangs or says "Connection refused," curl can't even start the SSL handshake.
• Is there a firewall blocking you? Internal networks often block port 443 for non-browser traffic. Test with a different port like 8443.
• Does the server use a different SSL library? Some old servers use SSLv3 or TLS 1.0, which macOS's curl may reject by default. You can try curl --tlsv1.2 https://your-server but that's rare.
• Is curl itself broken? Run which curl and curl --version. You should see "OpenSSL" or "SecureTransport" in the output. If it says something weird, reinstall curl via Homebrew.

I'll be honest: most people hit Fix 1, get frustrated they can't make it permanent, then jump to Fix 3 and forget about it. That's what I recommend. The 30-second fix confirms the server works. The permanent fix makes it just work forever.

And if you're the one generating self-signed certs for your team, use a proper tool like mkcert (it automates the Keychain step) or OpenSSL with a 10-year expiry. Saves everyone time.