Environment: Azure Kubernetes Cluster
Container: Dotnetcore 2.2 Linux
The dot-net core application was able to query the external partner API endpoint but suddenly it started throwing the below is the mentioned exception
ExceptionId: c6c603bb-91cc-4556-98bf-d747903f522a. Error Message: The SSL connection could not be established, see inner exception.. Error Details: System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Also tried the curl command from inside busybox pod and getting this error
Curl command : curl --location --request GET 'external url' --header 'Authorization: token'
Error:
curl: (60) SSL certificate problem: certificate has expired
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.
Note:
Other partner API calls are working fine, except this particular partner but the curl from the local system is working. From Pod, it is throwing an error.
What can be the issue:
External partner SSL expired. Which the partner is saying that it has not
External partner SSL is cached and now invalid in Kubernetes
Kubernetes configuration is the problem. What can be the correct one
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.
I'm currently trying to setup GlusterFS integration for a Kubernetes cluster. Volume provisioning is done with Heketi.
GlusterFS-cluster has a pool of 3 VMs
1st node has Heketi server and client configured. Heketi API is secured with a self-signed certificate OpenSSL and can be accessed.
e.g. curl https://heketinodeip:8080/hello -k
returns the expected response.
StorageClass definition sets the "resturl" to Heketi API https://heketinodeip:8080
When storageclass was created successfully and I try to create a PVC, this fails:
"x509: certificate signed by unknown authority"
This is expected, as ususally one has to allow this insecure HTTPS-connection or explicitly import the issuer CA (e.g. a file simply containing the pem-String)
But: How is this done for Kubernetes? How do I allow this insecure connection to Heketi from Kubernetes, allowing insecure self-signed cert HTTPS or where/how do I import a CA?
It is not an DNS/IP problem, this was resolved with correct subjectAltName settings.
(seems that everybody is using Heketi, and it seems to be still a standard usecase for GlusterFS integration, but always without SSL, if connected to Kubernetes)
Thank you!
To skip verification of server cert, caller just need specify InsecureSkipVerify: true. Refer this github issue for more information (https://github.com/heketi/heketi/issues/1467)
In this page, they have specified a way to use self signed certificate. Not explained thoroughly but still can be useful (https://github.com/gluster/gluster-kubernetes/blob/master/docs/design/tls-security.md#self-signed-keys).
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.
Firstly my exposure and experience with certificates is limited so I am trying to use this as a learning experience as well as obtaining an answer.
Using Jenkins I would like to be able to make a curl request as part of my build that uses a certificate (.p12) to authenticate.
Example
curl --cert /Users/Jenkins/.jenkins/workspace/develop-pipeline/../certificates/dev_cert.p12:password https://jira.dev.organisation.co.uk:443/rest/api/2/issue/MYSTATS-1234
So I have a Desktop certificate (private key) which I have saved onto the machine where Jenkins runs, but I also understand that I need a CA certificate to authorise this private key (hope this is correct so far).
When I have run the curl command from the terminal on the Jenkins machine I had a popup that asked me did I want to use the cert within the keychain to authorise and I clicked always allow, so command line curl requests always work.
However when I run this as part of a Jenkins build I get
(58) SSL: Can't load the certificate "/Users/Jenkins/.jenkins/workspace/develop-pipeline/../certificates/dev_cert.p12" and its private key: OSStatus -25308
The path to the cert is correct as the directory structure is
develop-pipeline
certificates
dev_cert.p12
What I don't understand is that if I don't provide a password
curl --cert /Users/Jenkins/.jenkins/workspace/develop-pipeline/../certificates/dev_cert.p12 https://jira.dev.organisation.co.uk:443/rest/api/2/issue/MYSTATS-1234
I get the message:
SSL The certificate "/Users/Jenkins/.jenkins/workspace/develop-pipeline/dev_cert.p12" requires a password
So it has found the certificate ?
Also providing an incorrect password yields
SSL: Incorrect password for the certificate "/Users/Jenkins/.jenkins/workspace/develop-pipeline/dev_cert.p12" and its private key.
What do I need to do to get this working?
This Github comment helped me sorting out the curl issue on OSX. So in my case installing curl via Homebrew with OpenSSL flags did the trick.
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.