I'm just following the basic documentation to call the DataPrep API:
https://cloud.google.com/dataprep/docs/html/API-Workflow---Run-Job_145281449
I got the Access Token ready but seems like DataPrep API has a expired certificate
$ curl 'https://api.clouddataprep.com/v4/jobGroups/$ID' -X GET -H 'Authorization: Bearer $TOKEN'
curl: (60) SSL certificate problem: certificate has expired
You can check: https://whatsmychaincert.com/?api.clouddataprep.com
Currently it says:
api.clouddataprep.com has a trusted chain containing an expired certificate. This chain will work with modern web browsers (they will use a chain to a different trusted root) but may fail with older clients, notably OpenSSL 1.0.x.
could you please try again, the certificates are fixed and you shouldn't see this issue anymore.
Related
I am using the curl terminal and while issuing the following command :-
curl --anyauth --user admin:admin "https://localhost:8000/LATEST/search?q=caesar"
I am getting below alert :-
curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
Please suggest. I have installed curl in Windows and also downloaded the .pem file and placed it in the same folder.
If your server has a self-signed cert, then by default curl doesn't know that it can trust that the server is who it says it is, and doesn't want to talk.
You can either:
import the cert into your trust store (best and most secure)
apply the -k or --insecure switch to ignore and continue. This may be fine for local development.
use a real cert, signed by a trusted CA
For local dev and a quick solution, run this line
set_config( config( ssl_verifypeer = 0L ) )
before
httr::GET(....)
but as suggested it's still preferable to use a real cert.
I am trying to call an URL using curl, I used below command:
curl https://testenvironment/login --cert Qa1Certificate.pem
The result I get is:
curl: (60) Peer certificate cannot be authenticated with known CA certificates
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.
The Qa1Certificate.pem is placed in the current directory, and I believe that it is not taken into consideration because when I run the same command with a file name which does not exist:
curl https://testenvironment/login --cert ThisFileDoesNotExist.pem
I get the same result.
I am aware that I can obtain what I need using the -k or --insecure options( or other ways of disabling curl's verification of the certificate), but I
want to find out how can I use the certificate in order to perform a successful GET to my test environment.
The test environment uses a self signed certificate which I obtained using openSSL.
TLDR: it's --cacert
From the man page, which should be on your system or on the web:
-E, --cert <certificate[:password]>
(TLS) Tells curl to use the specified client certificate file when getting a file with HTTPS, FTPS or another SSL-based protocol. [snip rest]
Note the words 'client certificate'. --cert is used to specify a certificate and possibly key to authenticate the client, NOT to verify the server.
Now consider another entry on the man page:
--cacert
(TLS) Tells curl to use the specified certificate file to verify the peer. The file may contain multiple CA certificates. The certificate(s) must be in PEM format. Normally curl is built to use a default file for this, so this option is typically used to alter that default file.
This is the option to specify a cert or certs to verify (and specifically to anchor) the server's cert. Since your server cert is selfsigned, the cert is its own anchor/root and effectively is a CA cert, even though the server isn't actually a CA.
That's why the error message you posted includes the words
you can specify an alternate file using the --cacert option.
It does not say --cert.
Whether the client cert (and key) is read depends on the middleware used by the specific build of curl you are running. IME if built with OpenSSL it does give an error if you specify --cert with a nonexistent filename, but a version built with NSS (on Ubuntu 14.04LTS) gives an error only if the server requests client auth, which most servers don't.
I am using cURL for Windows.
I'm following separate advice and have just about no idea what I'm doing, but I know what I've done:
C:\...> curl http://api.stackexchange.com/2.1/sites
<garbage, probably encrypted>
C:\...> curl https://api.stackexchange.com/2.1/sites
curl: (60) SSL certificate problem: unable to get local issuer certificate
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.
I haven't added any frills, but I do not have what you'd call a 'normal' installation; I've temporarily added the unzipped folder to my PATH, but it's on my desktop. I don't think this makes a difference but, again, I have no idea what I'm doing.
(If you're interested, I'm working on a Stack Exchange mode for Emacs.)
As you can see it is gzip
$ curl -I api.stackexchange.com/2.1/sites
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Length: 95
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
So
$ curl -s --compressed api.stackexchange.com/2.1/sites
{"items":[{"site_type":"main_site","name":"Stack Overflow","logo_url":"http://cd
n.sstatic.net/stackoverflow/img/logo.png","api_site_parameter":"stackoverflow","
site_url":"http://stackoverflow.com","audience":"professional and enthusiast pro
[...]
Tricky Tricky
I'm trying to access box.com with libcurl. To use SSL I exported the SSL certificates with my web browser, box.com uses certificates issued by GeoTrust. But even if I pass them to curl (also with the command line tool (curl https://www.box.com --cacert /certs.pem)) I get an error that curl can't verify the certificate.
If I do exactly the same with a different site, which uses certificates issued by CAcert everything works just fine.
Do I need more/different certificates for box.com, additional to the GeoTrust certificates shown by the browser? If I use the complete certificate bundle stored in my system at /etc/ssl/certs I can connect to box.com but how do I found out which certificates are needed?
If you simply want to get it working, you could set this attribute to false:
CURLOPT_SSL_VERIFYPEER
I have a server application which uses client certificate authentication. Each new user must get own certificate before he can use my application.
So, I want to use some utility to test user requests signed by x509 certificate. It can be any program or plugin for e.g. Chrome.
With best regards, Evgeniy
You can use a tool like curl with the --cert argument (see http://curl.haxx.se/docs/manpage.html) or wget with the --certificate argument (see http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html#HTTPS-_0028SSL_002fTLS_0029-Options). Either or both are present on most *nix systems but the download locations are:
curl: http://curl.haxx.se/download.html
wget: http://gnuwin32.sourceforge.net/packages/wget.htm