Bug #12737
closed
CA path is not defined when using ``curl`` in the shell
Added by Danilo Zrenjanin almost 3 years ago.
Updated almost 2 years ago.
Plus Target Version:
23.01
Description
When executing the curl command from the pfSense, CApath is not defined by default.
[2.5.2-RELEASE][admin@xxxx]/root: curl -v https://sede.mites.gob.es
* Trying 192.148.211.13:443...
* Connected to sede.mites.gob.es (192.148.211.13) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
* CApath: none
This is why curl ignores Trust Store CA (/etc/ssl/certs)
- Category changed from Unknown to Certificates
- Target version changed from 2.6.0 to 2.7.0
- Plus Target Version changed from 22.01 to 22.05
For reference, the cert store can be specified:
curl -vso /dev/null --cacert /etc/ssl/certs/a734448e.0 --connect-timeout 5 https://lanhost.lab.arpa --resolve 'lanhost.lab.arpa:443:172.19.5.100'
- Plus Target Version changed from 22.05 to 22.09
- Plus Target Version changed from 22.09 to 22.11
Same issue here, curl doesn't use the trust store and it seems neither does pfBlockerNG. Seems a bit laughable that if you have a corporate CA, you can't verify internal certificates on the firewall. Turning SSL off is obviously easy, but not the right choice.
Djerk Geurts wrote in #note-6:
Same issue here, curl doesn't use the trust store and it seems neither does pfBlockerNG. Seems a bit laughable that if you have a corporate CA, you can't verify internal certificates on the firewall. Turning SSL off is obviously easy, but not the right choice.
There's no real good way I've found to change the trust store to some directory. This particular issue with pfBlockerNG/aliases is a related but separate issue.
- Related to Feature #13367: Specify CA trust store location when downloading and validating URL alias content added
- Plus Target Version changed from 22.11 to 23.01
- Assignee set to Jim Pingle
Seems like we should be able to define our CA path in the environment to cover some of these cases:
From the man page for curl:
SSL_CERT_DIR <dir>
If set, will be used as the --capath value.
See similar setup we have for proxy and so on in source:src/etc/skel/dot.shrc and source:src/etc/skel/dot.tcshrc
We should be able to set SSL_CERT_DIR=/etc/ssl/certs/ to pick up and custom globally trusted CA entries.
: env SSL_CERT_DIR=/etc/ssl/certs/ curl -v https://www.netgate.com
[...]
* Connected to www.netgate.com (199.60.103.30) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /usr/local/share/certs/ca-root-nss.crt
* CApath: /etc/ssl/certs/
[...]
That wouldn't have any bearing on cURL calls made within PHP, those would need to be changed individually.
- Status changed from New to In Progress
Defining it in the environment in the shell init scripts works for me. Commit inbound shortly.
With the CA for a web server imported but not marked as globally trusted:
: curl https://my.test.host
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.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.
Mark the imported CA for that web server as globally trusted and try again:
: curl https://my.test.host
:
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
- Subject changed from CApath is not defined by default in curl to CA path is not defined when using ``curl`` in the shell
Updating subject for release notes.
- Status changed from Feedback to Resolved
Working as expected. Mark a CA as trusted and cURL in a shell prompt can connect to a server with a cert signed by that CA with validation enabled. Remove it from the trust store and the same request fails.
Also available in: Atom
PDF
Updated by Viktor Gurov 
Updated by 
Updated by 
Updated by