curl --cacert / --cert: Trust and Client Certs
The safe answer to a TLS error is to add trust, not to remove verification.
When you talk to internal services with a private CA or mutual TLS, these flags configure trust properly instead of using -k.
What it does
--cacert <file> points curl at a CA certificate bundle to verify the server against, which is how you trust an internal CA without disabling verification. --capath <dir> uses a directory of hashed CA certs. For mutual TLS, --cert <file> presents a client certificate and --key <file> supplies the matching private key. These keep verification on while making the right certs available.
Common usage
curl --cacert ./internal-ca.pem https://internal.example.com/x
curl --cert ./client.pem --key ./client.key https://mtls.example.com/x
curl --cert ./client.p12:password --cert-type P12 https://mtls.example.com/xFlags
| Flag | What it does |
|---|---|
| --cacert <file> | CA bundle to verify the server certificate |
| --capath <dir> | Directory of trusted CA certificates |
| --cert <file> | Client certificate for mutual TLS |
| --key <file> | Private key matching the client certificate |
| --cert-type <t> | Certificate format, for example PEM or P12 |
In CI
Write the CA and client cert from secrets to a temporary file at the start of the job and pass them with --cacert / --cert. This keeps TLS verification enabled, which -k would throw away. Clean up the temp files at the end so keys do not linger on the runner.
Common errors in CI
curl: (58) unable to set private key file means --key is wrong or password-protected; check --key and --pass. curl: (60) ... unable to get local issuer certificate means the server chain is not covered by --cacert; supply the full chain.