Good afternoon, dear community!
I ask for help from those who had the relevant experience.
I am making an API request to https://ssl.croinform.ru:450. For example, an authentication request: curl -k POST https://ssl.croinform.ru:450/api.test?Type=Login&Login=testUser&Password=testPassword but I get the error. The error text differs depending on the environment where I am running the curl command.
On windows I experiment in git bash (curl version 7.77.0) and Cygwin64 (curl version 7.78.0), get the same error: curl: (35) error: 14094410: SSL routines: ssl3_read_bytes: sslv3 alert handshake failure.
В CentOS7 (curl version 7.78.0): curl: (6) Could not resolve host: POST
curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).
The service provides certificates that need to be installed on your OS: cacer.p7b, ssl.croinform.cer. As recommended in the service documentation, on windows I installed them in Trusted Root Certification Authorities. There is no support recommendation for CentOS7, but I put the certificates at / etc / pki / ca-trust / source / anchors / and ran the update-ca-trust enable and update-ca-trust extract commands. These actions do not solve the problem.
Please tell me what I am doing wrong.
Thanks in advance!
your error shows the protocol to use is SSL version 3 and the handshake is failing to agree to use this protocol to communicate with SSL.
plus this may be unsupported now, the latest TLS versions are TLS 1.1 and 1.2
you could try a different protocol version for example,
curl --tlsv1.2
To use tls 1.2 but have a look at the documentation for other protocols also.
If this is a test you can allow insecure connections with the curl -k parameter
Related
I am trying to install and setup Elasticsearch on a remote Machine running CenOS7 via this guide. Following the install and start instructions for RPM I entered the cURL command given on the guide to check its up and running: curl --cacert $ES_PATH_CONF/certs/http_ca.crt -u elastic https://localhost:9200
I was met with the following message:
curl: (77) Problem with the SSL CA cert (path? access rights?)
I tried to go to the domain with the following command:
curl https://localhost:9200/
And was met with this:
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
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.
So I tried the previous command once adding a '-k' but was met with this error:
{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}
I was able to complete the guide on my MacBook but have almost no experience working with remote machines or in CentOS 7. How do I successfully cURL the cluster information?
I am trying to access the Outlook mail server via IMAP using PHP. As this is not working as intended and the error messages are not helping, I looked up ways to test the basic connectivity and came across the following line of code:
openssl s_client -connect outlook.office365.com:993
This should, supposedly, let me connect to the mail server using an encrypted connection, so that I can then issue some commands to actually log in etc.
However, the command only generates the following output:
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 313 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
I have tried researching the error message (write:errno=104), which lead to some suggestions like enforcing TLSv1.2 using the -tls1_2 parameter, neither of which made any difference.
Can someone point me in the right direction? I already ran this command on Ubuntu and Windows 10 using the latest version of OpenSSL.
I can connect using your command, but I needed to force \r\n line ending characters using the -crlf option when connecting in order to be able to type commands and have the server recognise them.
You can also add -quiet to reduce the amount of output:
openssl s_client -connect outlook.office365.com:993 -crlf -quiet
However, it seems the connection is getting reset in your case. This means there's some sort of network issue. There might be a firewall blocking your access to port 993 on outlook.office365.com. e.g. this might be the case if you normally have to connect via a proxy server.
Recent versions of openssl s_client have a -proxy option, but don't seem to allow specifying a proxy username and password. Also it might not work with your proxy even if you don't need to authenticate to the proxy server. One workaround might be to use http://ntlmaps.sourceforge.net/. I have tried it in the past, but it was over 15 years ago.
You could also try using cURL's IMAP support instead of openssl s_client, since it has better proxy support.
Another possibility is to connect to port 143 and use STARTTLS instead of connecting to port 993. Obviously if port 993 is firewalled then port 143 might also be, but in your case it seems like it is allowed:
openssl s_client -connect outlook.office365.com:143 -starttls imap -crlf -quiet
If you are behind a proxy and can't connect to the IMAP server directly, then you can also use something like EmailEngine that handles connections itself and allows access mailbox contents via a REST API.
Note: this is not a duplicate of openssl s_client using a proxy, as I am specifically interested in proxy authentication, not the ability to use proxy.
I'm using openssl s_client to inspect certificates of the target server to understand how/where the connection works or not. As I'm behind a corporate proxy, I can specify the proxy server with -proxy flag, however I need to pass authentication details (username/password) to this proxy - and I haven't figured out how to do that.
openssl s_client -proxy my.proxy.server:8080 -connect my.target.host
successfully connect to the proxy server, however, understandably, results in error s_client: HTTP CONNECT failed: 407 Unauthorized.
Passing proxy server in the form of user:pass#my.proxy.server or http://user:pass#my.proxy.server both result in error s_client: -proxy argument malformed or ambiguous.
How can I pass proxy authentication to s_client? I would find it hard to believe that it supports proxy but not authenticated proxy.
I'm using openssl version 1.1.1a.
Just to follow up on #Arnaud Grandville's answer: OpenSSL v3 beta 1 has now been released, and it includes proxy authentication options. You have to compile it yourself, however.
Unfortunately in v3 beta 1 the HTTP code had some issues so you can't use the code from their website as-is. Anyone looking to compile from source can use the commands below to get an OpenSSL installation with working proxy authentication:
git clone --branch openssl-3.0.0-beta1 https://github.com/openssl/openssl.git
cd openssl
git fetch
git checkout 6a1f9cd -- crypto/http/http_client.c
./Configure
make
make install
Edit: For later versions this is no longer necessary as the bug was fixed. For example for version 3.0.5 you can simply run:
git clone --branch openssl-3.0.5 https://github.com/openssl/openssl.git
cd openssl
./Configure
make
make install
You can use escape-from-intranet https://github.com/quaddy-services/escape-from-intranet#introduction
and specify
host=my.proxy.server
port=8080
in the app and use
openssl s_client -proxy localhost:3128 -connect my.target.host
and your local running application will enrich the real proxy call with your credentials.
(In case you have a transparent proxy you need to switch the default proxy decision to "PROXY" in the "Decision" Menu)
openssl v3.0 will supports proxy_user and proxy_pass options.
no solution for now, the syntax after proxy is
host + ':' + service
host + ':' + '*'
host + ':'
':' + service
'*' + ':' + service
host
service
cf. BIO_parse_hostserv
I would like to try and use Tornado's proxying capabilities. For this, the documentation tells me, I need to have libcurl compiled with asynchronous DNS resolver.
I have a version of libcurl installed via yum (7.29), but I can't figure out how to tell whether it was built with asynchronous DNS resolution or not.
If it doesn't, is there a way to enable it, or do I have to build it from scratch? It seems like the latter is the only option I could find so far, hoping I missed something.
Thanks!
Alternatively, if you have command-line version of curl installed, you may run curl --version. To install curl on alpine run apk add curl
Example output:
root#ae5870274e10:/mnt/src# curl --version
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP
and look for AsynchDNS keyword
Call curl_version_info() and check the returned struct and its 'features' field:
int features; /* bitmask, see below */
If that field has the bit CURL_VERSION_ASYNCHDNS set, you know this libcurl build resolves names asynchronously. Using either threads or it was built to use c-ares.
If that bit is not set, it was built to use synchronous name resolves.
I made my own git server on a centos distribution.
I can contact the server via git protocol at my home. But when I try to access via https at office I obtain:
Cloning into /Users/vito/Documents/... error:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while
accessing https://gitolite#myserverxyz.com/vitorepo.git/info/refs
fatal: HTTP request failed
Where is the problem? On my server or on my office-mac?
I got the exact same response from curl when trying to connect with an ubuntu instance running openssl 1.0.0e. I successfully resolved the problem by adding the -ssl3 flag to the curl command.
It seems that it's a compatibility problem between older version of OpenSSL (0.9.8) acting as a client and recent OpenSSL version (1.0.0) acting as a server with some specific options used by Curl on client side and Apache on server side.
It's probably due to some recent security fix in OpenSSL (probably the one against protocol downgrade attacks).
Try upgrading the OpenSSL library version on the client side to 1.0.0.
See:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976
In case anyone has this issue with XMLRPC.
Daniel's answer (forcing SSL version 3) solved the issue for me. just specify XMLRPC_SSLVERSION_SSLv3 in the clientXmlTransport_curl options (C++).
The problem began when we upgraded our server to OpenSSL version 1.0.1-4ubuntu5.5 and the clients were still running 0.9.8o-5ubuntu1.7.
I believe this is a host-name matching issue on the server. Error 1112 is SSL_R_TLSV1_UNRECOGNIZED_NAME, and comes from an SNI name mismatch (info on SNI). I was having the same issue in curl.
For me, the work around was to make sure the name I used on the client matched one of the ServerName or ServerAlias configurations on the server. Of course, these commands are for an apache server; I don't know what you need to do for a git server. But I suspect the server names you're using from home and work are different, and the home name is the cannonical name the git server is using (and therefore SNI is working).
The 'real' fix will probably take a client change in git to allow a way to ignore the name-mismatch warning (the way your browser already does).
Not sure if I had exactly the same problem, but the error message was the same. It only seemed to be happening on the ubuntu box I set up a git server on, for some reason the centos box with a git server set up on it was fine.
I only just solved it after 3 or 4 days. It turns out to be because git's underlying Curl library has a broken Keep-alive implementation (I ended up dumping HTTP traffic and verifying the behaviour by hand).
In a nutshell Curl (at least the version used inside every Git implementation I could find, including command line git and eclipse's EGit) doesn't seem to correctly interpret the Connection response header, or more correctly doesn't seem to correctly interpret the absence of it.
To fix the problem you need to configure the SSL virtual host inside the apache that is serving your GIT repository with an extra directive specifically for git. Add these lines just before the </VirtualHost>.
BrowserMatch "git" nokeepalive ssl-unclean-shutdown
You unfortunately can't tell apache to just downgrade to HTTP/1.0 (would be cleaner) because Curl can't handle that, but you can just tell it to force a Connection:close on every request which Curl does know how to handle.
In a misleading coincidence, if you try to test Curl directly without this change it will seem to work, because it makes a single request and then aborts. Only by getting curl to execute two requests on the same keep-alive connection over ssl will this problem become apparent.
I had the same error. The root cause seems to be incompatibility of client/server openssl versions.
I've upgraded my server with apt-get upgrade openssl and upgraded my windows git installation.
The combination of windows git client
git version 1.9.4.msysgit.0, which contains openssl version:
OpenSSL 0.9.8e 23 Feb 2007
And server with openssl version:
OpenSSL 1.0.1c 10 May 2012
seems to work fine together.