I've been playing around with Curl, trying to do what should be a simple POST of a file to a web service for a couple of days and not getting anywhere.
The target POST service is unauthenticated HTTPS. When trying to run my POST request via Curl or via Informatica, I am getting an SSL handshake failure with both methods.
For example:
curl -X POST -F 'file=#filename.dat' https://url
I have been able to get this to work using Postman, so I know the service works. According to network security, SSL is disabled in this environment. Am I out of luck, or is there a way to get this to work without SSL?
Specific error encountered:
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
By default, a client establishing a HTTPS URL connection will check the validity of a SSL certificate - otherwise, what's the point of using SSL?
In your case, you are saying "Pretend to use HTTPS but actually, ignore the certificate", because it's invalid, or you are still getting one, or you are in the development phase (I hope the latter is true, and get or create a valid sever certificate when needed).
But curl doesn't know that. It is assuming you are asking it to establish a connection with an HTTPS endpoint - thus it will try to validate the certificate - which, in your case, may be the source of the failure.
Try curl -k -X POST -F 'file=#filename.dat' https://url
From the manpage:
-k, --insecure
(TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even for server connections otherwise considered insecure.
The server connection is verified by making sure the server's certificate contains the right name and verifies successfully using the cert store.
See this online resource for further details:
https://curl.haxx.se/docs/sslcerts.html
See also --proxy-insecure and --cacert.
Related
I need to get information about a VM using curl with REST calls. I have this information where 1701 is the VM ID
GET /api/v1/vms/1701 HTTP/1.1
Host: vmlam.ral.sf.com
Authorization: Token token=4210
I tried this in cygwin but it did not work
c:/curl-7.69.0-win64-mingw/bin/curl -X GET -d '{Authorization: Token token=4210}' 'https:/vmlam.ral.sf.com//api/v1/vms/1701'
curl: (60) SSL certificate problem: unable to get local issuer
certificate More details here: curl.haxx.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.
That seems like a certificate issue, you can skip the check with the option -k (or --insecure)
From curl documentation (man curl):
-k, --insecure
(TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even for server connections other‐
wise considered insecure.
The server connection is verified by making sure the server's certificate contains the right name and verifies successfully using the cert store.
See this online resource for further details:
https://curl.haxx.se/docs/sslcerts.html
See also --proxy-insecure and --cacert.
Background:
I have a running app at ports 8080 in the remote server and a https ingress proxy at 443 on the same server, which redirects everything to 8080 app after handling the SSL.
What I want to do:
I want to communicate with the app through SSL remotely, while not having access directly to this domain (it is on a local network, I can access the server remotely via a different domain).
What I did:
I tunneled 443 port from my remote server ssh -L 3001:0.0.0.0:443 user#example.com. I then added 127.0.0.1 example.com to my /etc/hosts to make sure that the domain on my system is resolved properly.
Now, what I can do is enter https://example.com:3001/some/thing/ in firefox and it gets me a proper response from the server, while everything is ran through ssl without any problems. I also am able to use curl without checking the certificate: curl --insecure https://example.com:3001/some/thing works fine.
At the same time secure curl call fails: curl https://example.com:3001/some/thing with the error:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
Just to make sure both are using the same certificates, I actually used this tool: https://curl.haxx.se/docs/mk-ca-bundle.html to create a ca-bundle.crt from the most recent firefox certificates and passed it to curl with --cacert ca-bundle.crt. No luck - the same error. (I also tried following other curl tutorial on getting the local installation of firefox's certs, also no luck).
Question
What is going on? Why is curl's output different from firefox's even if I seem to use the same certificates? How can I debug this?
Side note
The real reason I am concerned about it is that with a normal (local) access to the server, I observed the same behaviour: I could connect to the server through chrome on https, but my react native app could not. I suspect the app to use libcurl under the hood or something similar and I believe debugging this problem could help me understand what's the problem with the app.
I'm trying to use curl to access a URL of an app we've developed internally, and on the server I'm seeing
http: TLS handshake error from 1.2.3.4 remote error: tls: unknown certificate authority.
This only happens when we hit the endpoint using curl (inside git bash ) or wget. When we use IE on Windows it works just fine. I've even tried re-installing git bash using Native SSL library (which should be the same as IE), but still getting the same error message.
Have even tried downloading the curl-ca-bundle.crt file and saving to the same place as the curl binary, or even directly telling it to use this file with curl --cacert option, but still no joy.
I've compared the root certs that IE is reporting, and the ones in that curl-ca-bundle.crt and they look the same (they don't line up exactly the same, but they have the same text in them between the BEGIN and END markers, one is just wider on the screen and therefore uses fewer lines if that makes sense).
Hopefully someone has ideas what to try next as two of us have been tearing our hair out all afternoon with this.
wget also gives an error message :-
$ wget https://bler.com/admin/user
--2018-09-03 15:53:43-- https://bler.com/admin/user
Connecting to 132.146.1.142:8090... connected.
ERROR: cannot verify oss.dns.networks.bt.com's certificate, issued by 'CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US':
Unable to locally verify the issuer's authority.
To connect to oss.dns.networks.bt.com insecurely, use '--no-check-certificate'.
We're using a local proxy server, and HTTP_PROXY is set. It must be using the proxy, as we can see we're hitting the end point.
I also had the same error. This problem occurs when you install on Golang web server the only certificate. You must use a certificate chain instead.
For example, Letsencrypt gives "cert.pem" and "fullchain.pem". "cert.pem" works in browsers, but curl cannot work with this file (curl: (60) SSL certificate problem: unable to get local issuer certificate). "fullchain.pem" works fine in browsers and curl.
I am trying to test a cURL command from my server. The command is requesting a JSON response from a URL that is https.
The cURL seems to be stuck, with no response and it doesn't time out.
However, I have tested it from my local machine and the cURL command works fine.
Do I need an SSL certificate installed on the server for it be able to send cURL commands to an https URL?
No you don't need an SSL cert to send a command like curl via https (unless your server uses two way ssl).
You DO need one at the other end for the https server that receives the command from curl.
However if it's a self signed cert then it may not be recognised by curl and you may get an error instead of a successful connection.
The fact the process is hanging suggests a network/connectivity issue rather than an SSL issue. Can you telnet to the machine using port 443 or does that hang too?
telnet www.example.com 443
Should respond.
I want to use Cloudify 3.1 with my Openstack in my company.
Unfortunately, I had the prolem that the keystone authentication failed.
When I see the log,it says,"SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"
I think it is HTTPS that make it failed. I see the curl below.
curl -i 'https://identity.example.com/v2.0/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "xxxx", "passwordCredentials": {"username": "xxxx", "password": "xxxxx"}}}'
HTTP/1.0 200 Connection Established
Proxy-agent: Apache
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
How can I make the curl succeed without using -k or --insecure?
OR IF ANYONE HAS THE EXPERIENCE TO DO WITH openstack THAT KEYSTONE IS USING HTTPS WHEN INSTALLING Cloudify?
Using Openstack services with insecure SSL certificates is not possible in Cloudify 3.1. However, in Cloudify 3.2 it's possible to pass the --insecure (or ca_cert) flags directly to be used by the Openstack clients.
You can read the documentation for this feature here:
http://getcloudify.org/guide/3.2/plugin-openstack.html#openstack-configuration
So, for example, to use Nova service with insecure certificate, your Openstack configuration could look something like this:
openstack_config:
...
custom_configuration:
nova_client:
insecure: true
Hope this helps.
The SSL certificate could be invalid for a number of reasons. I've even seen where people forgot to reload the web server after updating the certificate. But, it is telling you what the overall problem is - you need a valid SSL certificate that is installed correctly.
Using curl -k or curl --insecure is perfectly fine in a development environment. For production, you can use an SSL Checker to test the SSL certificate and find out why it is being reported as invalid.
Recently,I look the github of cloudify.
They are resolving my problem,the problem linkenter link description here
the work is on progressing.