Is there anything special that has to be done to allow SSL SNI to work from iOS? We have some common code that is using CURL that works on our Android side and not on the iOS Side. We are getting https error.
SSL Connect Error
Could not get any more information from the call / get, status is 0, etc.
Is there some special PLIST items that have to be added to support SSL SNI?
---- addition ----
We are using the AWS Cloud Front for this and are looking into the exact versions of all
---- addition -----
verbose output
* Trying xx.xx.xx.xxx...
* TCP_NODELAY set
* Connected to xx.xx.com (xx.xx.xx.xxx) port 443 (#0)
* SSL peer handshake failed, the server most likely requires a client certificate to connect
* Curl_http_done: called premature == 1
* Closing connection 0
This is common code that Android is using also and is working fine.
we are also setting this for testing
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);
Related
Background
I have a Ubuntu and I am trying to install Erlang 22.2.8 via the asdf-erlang plugin.
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
Problem
In fact, I want to install any version of Erlang, but none works.
$ asdf install erlang 22.2.8
Downloading kerl...
$
It stops after "Downloading kerl" and then nothing happens. It is like it finished.
I have followed the steps before-asdf-install also before installing the plugin, but non the less this does not prevent the error.
How can I fix this?
After a lot of investigation by me and several people from the Elixir community, we have finally discovered what was the issue.
Issue
The first clue was the exit signal of the command itself:
$ asdf install erlang 22.2.8
Downloading kerl...
$ echo $?
1
The exit code is 1. Which means an error was occurring.
So after digging into the code, we found there was a curl call I was not able to make:
$ curl -v -Lso ~/.asdf/plugins/erlang/kerl https://raw.githubusercontent.com/kerl/kerl/2.0.2/kerl
* Trying 151.101.16.133:443...
* TCP_NODELAY set
* Connected to raw.githubusercontent.com (151.101.16.133) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3400 bytes data]
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
} [2 bytes data]
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
I was having SSL certificate issues. This is happening because of the company VPN/Proxy.
A quickfix/workaround could be found using the -k option to allow the curl to connect to insecure connections. After trying that curl with -k the request succeeded, which proved the theory correct.
Solution
With the issue identified, it was time to search for a solution. The solution I believe would be the most adequate, would be to add the company certificates to ssl certs.pem. This is described better in the following SO post:
How to fix "SSL certificate problem: self signed certificate in certificate chain" error?
Quick workaround
However, that solution didn't work me. So I eventually decided to go with the risky option, which was to use the ~/.curlrc.
https://ec.haxx.se/cmdline/cmdline-configfile#default-config-file
After setting up this file and adding the -k option in it, it worked. I can now finally install the erlang versions I need.
It should be noted, this is a risk. In fact, this is a workaround and not really a solution.
However, for the time being, I will happily take it.
History
This is a summary of the whole discussion I had with the Elixir community. If you are interested in the full process, you can check the post:
https://elixirforum.com/t/installing-erlang-via-asdf-on-ubuntu-fails-after-downloading-kerl/36806/25
I have configured a freeradius proxy (3.0.16) on Ubuntu (4.15.0-47-generic). It receives the radius accounting packets from another radius server running on Ubuntu and writes those to another radius server on running on Fortigate.
Radius Server ---> Proxy Radius Server ---> Fortigate Radius Server
I have configured copy-acct-to-home-server to include the Realm in proxy.conf
proxy.conf ( Realm definition )
home_server myFortigate {
type = acct
ipaddr = <IP address of Fortigate Interface Running Radius>
port = 1813
secret = superSecret
}
home_server_pool myFortigatePool {
type = fail-over
home_server = myFortigate
}
realm myFortigateRealm {
acct_pool = myFortigatePool
nostrip
}
copy-acct-to-home-server entry
preacct {
preprocess
update control {
Proxy-To-Realm := myFortigateRealm
}
suffix
}
After I run the freeradius -X, I also run tcpdump from a new session
tcpdump -ni eth01 port 1812 or port 1813
and get the following log
15:03:40.225570 IP RADIUS_PROXY_IP.56813 > FORTIGATE_INTERFACE_IP.1813: RADIUS, Accounting-Request (4), id: 0x31 length: 371
15:03:40.236155 IP FORTIGATE_INTERFACE_IP.1813 > RADIUS_PROXY_IP.56813: RADIUS, Accounting-Response (5), id: 0x31 length: 27
Which basically shows it is sending the account request to fortigate radius server and receiving the accounting response.
But strangely freeradius -X debug output shows a request time out for the same radius server on Fortigate and it ultimately tags the server as zombie
Starting proxy to home server FORTIGATE_INTERFACE_IP port 1813
(14) Proxying request to home server FORTIGATE_INTERFACE_IP port 1813 timeout 30.000000
Waking up in 0.3 seconds.
(14) Expecting proxy response no later than 29.667200 seconds from now
Waking up in 3.5 seconds.
and Finally it gives up
25) accounting {
(25) [ok] = ok
(25) } # accounting = ok
(25) ERROR: Failed to find live home server: Cancelling proxy
(25) WARNING: No home server selected
(25) Clearing existing &reply: attributes
(25) Found Post-Proxy-Type Fail-Accounting
(25) Post-Proxy-Type sub-section not found. Ignoring.
So the situation is the Radius proxy is sending accounting packets to Fortigate Radius server (could be seen in both freeradius and fortigate logs)
tcpdump shows that Radius proxy is receiving accounting response from the fortigate, but for some reason freeradius process doesn't recognize (or can not read) accounting response. It may be some interoperability issue or I have missed to set some flag. Requesting help from the experts to isolate and rectify the issue.
In an effort to be OAuth'd with Etsy, I have tried countless solutions in C# to at least start the authentication process (ie get the login URL):
eg
mashery.com, http://term.ie/oauth/example/client.php and question #8321034
but the response is always the same:
oauth_problem=signature_invalid&debug_sbs=GET&https%3A%2F%2Fopenapi.etsy.com%2Fv2%2Foauth%2Frequest_token&oauth_consumer_key%3D...my-consumer-key...%26oauth_nonce%3D2de91e1361d1906bbae04b15f42ab38d%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1502362164%26oauth_version%3D1.0%26scope%3Dlistings_w%2520listings_r
and so I'm resorting to the dreaded world of PHP...
On my machine, I've installed the following (Windows 10):
XAMPP (xampp-win32-7.1.7-0-VC14-installer) with default options
JDK (jdk-8u144-windows-i586)
JRE (jre-8u144-windows-i586)
php_oauth.dll ([php_oauth-2.0.2-7.1-ts-vc14-x86.zip][4]) and copying it to C:\xampp\php\ext
[cacert.pem][4], (dated Jun 7 03:12:05 2017) and coping it to the following directories:
C:\xampp\perl\vendor\lib\Mozilla\CA
C:\xampp\phpMyAdmin\vendor\guzzle\guzzle\src\Guzzle\Http\Resources
Apache and Tomcat would not run to begin with from XAMPP because it said that ports 443 and 80 were being used/blocked and so I duly changed these to 444 and 122 in
C:\xampp\apache\conf\extra\httpd-ssl.conf
C:\xampp\apache\conf\httpd.conf
All good so far but when I run the following script in my browser (http://localhost:444/dashboard/etsy.php):
<?php
$base_uri = 'https://openapi.etsy.com';
$api_key = 'my-etsy-api-key';
$secret = 'my-etsy-api-secret';
$oauth = new OAuth($api_key, $secret, OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);
$req_token = $oauth->getRequestToken($base_uri .= "/v2/oauth/request_token?scope=listings_w%20transactions_r", 'oob');
$login_url = $req_token['login_url'];
print "Please log in and allow access: $login_url \n\n";
$verifier = readline("Please enter verifier: ");
$verifier = trim($verifier);
$oauth->setToken($req_token['oauth_token'], $req_token['oauth_token_secret']);
$acc_token = $oauth->getAccessToken($base_uri .= "/v2/oauth/access_token", null, $verifier);
$oauth_token = $acc_token['oauth_token'];
$oauth_token_secret = $acc_token['oauth_token_secret'];
$oauth->setToken($oauth_token, $oauth_token_secret);
print "Token: $oauth_token \n\n";
print "Secret: $oauth_token_secret \n\n";
?>
I get the following error message:
Fatal error: Uncaught OAuthException: making the request failed (Peer
certificate cannot be authenticated with given CA certificates) in
C:\xampp\htdocs\dashboard\etsy.php:8 Stack trace: #0
C:\xampp\htdocs\dashboard\etsy.php(8):
OAuth->getRequestToken('https://openapi...', 'oob') #1 {main} thrown
in C:\xampp\htdocs\dashboard\etsy.php on line 8
I've tried running the script with each thread safe, x86 version of OAuth (http://windows.php.net/downloads/pecl/releases) - stop, restart Apache) but no luck.
I'm at my wits end.
How to I resolve this Peer certificate problem?
Simply disable the SSL on local.
$oauth->disableSSLChecks()
Oauth by default using CURL SSL Certificate. The simple way for local apache server is to disable it. Either configure the SSL for the CURL. It will also resolve the issue for oauth.
as per php documentation
we can set the certificate path simply.
$oauth->setCAPath("F:\xampp\php\extras\ssl\cacert.pem");
print_r($oauth->getCAPath());
You can also set the request engine to curl or php stream if the ssl is already configured.
Official PHP documentation
I am trying to use SSL with MQTT and gets following error,
1379677998: Client connection from 127.0.0.1 failed: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number.
1379678058: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1379678058: Socket read error on client (null), disconnecting.
My conf file has seetings as below,
port 8883
cafile /home/administrator/Downloads/mosquitto-1.2.1_dilip/test/ssl/test-root-ca.crt (also tried all-ca.crt here)
certfile /home/administrator/Downloads/mosquitto-1.2.1_dilip/test/ssl/server.crt
keyfile /home/administrator/Downloads/mosquitto-1.2.1_dilip/test/ssl/server.key
tls_version tlsv1
require_certificate true (tried commenting this too)
and I run, 08-ssl-connect-cert-auth.test from test folder. code snippet included below
mosquitto_tls_opts_set(mosq, 1, "tlsv1", NULL);
mosquitto_tls_set(mosq, "../ssl/test-root-ca.crt", "../ssl/certs", "../ssl/client.crt", "../ssl/client.key", NULL);
mosquitto_connect_callback_set(mosq, on_connect);
mosquitto_disconnect_callback_set(mosq, on_disconnect);
rc = mosquitto_connect(mosq, "localhost", 8883, 60);
Environment info:
Python 2.7.3
OpenSSL 1.0.1 14 Mar 2012
Description: Ubuntu 12.04.2 LTS
Release: 12.0
mosquitto-1.2.1/mosquitto-1.2
Please let me know what could go wrong here? I also tried generating certificates using gen.sh.
Thanks in advance.
-Dilip
On a general note - you should be generating your own certificates, don't use the ones provided by mosquitto for testing, or use the gen.sh script without modifying it for your own details.
To use the certificates provided, you should be using all-ca.crt in the broker. It contains the example root CA and intermediary CA certificates. The client only requires the root CA for verification purposes.
You are using a full path to the certificates in the broker configuration, but relative paths in the client. Are you sure that they are both correct?
Have you tried running the tests unmodified with make test? This would tell you if there is a problem with your openssl installation for example.
I'm trying to setup secure connection to HTTPS server with curl on iOS (app is written in C++)
I figured out that I need to set cacert.pam (http://curl.haxx.se/ca/cacert.pem) file path for CURLOPT_CAPATH option:
curl_easy_setopt (curl, CURLOPT_CAPATH, "/var/mobile/Applications/811DEF2E-DE1D-4C86-A1FD-129478C8318D/MyApp.app/ca/cacert.pem");
curl_easy_setopt (curl, CURLOPT_SSL_VERIFYPEER, 1L);
curl_easy_setopt (curl, CURLOPT_SSL_VERIFYHOST, 2L);
But this just generates folowing verbose log (ip and url changed):
libcurl/7.29.0 OpenSSL/1.0.1e zlib/1.2.5
* About to connect() to myserver.com port 443 (#0)
* Trying 128.128.128.128...
* Connected to myserver.com (128.128.128.128) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /var/mobile/Applications/171CA93F-15F2-42A1-938B-01812AF1E555/MyApp.app/ca/cacert.pem
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Same happens if I set CURLOPT_CAPATH to "../MyApp.app/ca" folder. File exists and can be read.
There seems to be a lack of information about this error..
What I am doing wrong?
OK, after some irritating searching I found the problem and solution.
This does not seem to work neither with folder nor with file path:
curl_easy_setopt (curl, CURLOPT_CAPATH, caCertPath);
But this works when supplying full path to PEM file:
curl_easy_setopt (curl, CURLOPT_CAINFO, caCertPath);
Hope this helps someone in the future
from manual:
The CURLOPT_CAPATH function apparently does not work in Windows due to
some limitation in openssl
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html
CURLOPT_CAINFO option works