The trouble showed itself yesterday - getting following answer from curl (called in php script by curl_exec):
$<errno>35</errno>
$<error>Unknown SSL protocol error in connection to w3s.webmoney.ru:443 </error>
That bug happens only sometimes, something around 4-5 valid responses to one invalid with 35 error. Before yesterday application was handling those requests correctly for a very long time.
Hope someone will give me a hint about possible reasons of that bug.
P.S. We are suffering from internet connection problems lately, can it be somehow connected to that bug?
Upd:
Setting verbose output to true made curl to write following log:
* About to connect() to w3s.webmoney.ru port 443 (#0)
* Trying 82.198.171.158... * connected
* Connected to w3s.webmoney.ru (82.198.171.158) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: ${path}/WebMoneyCA.crt
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=RU; O=WebMoney Transfer; OU=WebMoney Web Service; CN=w3s.webmoney.ru
* start date: 2010-06-07 10:03:43 GMT
* expire date: 2012-06-07 10:13:43 GMT
* common name: w3s.webmoney.ru (matched)
* issuer: OU=WM Transfer Certification Services; O=WM Transfer Ltd; CN=WebMoney Transfer Root CA
* SSL certificate verify ok.
> POST /asp/XMLPurses.asp HTTP/1.1
Host: w3s.webmoney.ru
Accept: */*
Content-Length: 281
Content-Type: application/x-www-form-urlencoded
< HTTP/1.1 200 OK
< Date: Fri, 10 Dec 2010 13:00:04 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< Content-Length: 4423
< Content-Type: text/xml; Charset=windows-1251
< Expires: Fri, 10 Dec 2010 13:00:04 GMT
< Set-Cookie: ASPSESSIONIDQADQDTAQ=FJMNECHBENFFAADHEHPFOKAE; path=/
< Cache-control: private
<
* Connection #0 to host w3s.webmoney.ru left intact
* Closing connection #0
* About to connect() to w3s.webmoney.ru port 443 (#0)
* Trying 212.158.173.158... * connected
* Connected to w3s.webmoney.ru (212.158.173.158) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: ${path}/WebMoneyCA.crt
CApath: /etc/ssl/certs
* Unknown SSL protocol error in connection to w3s.webmoney.ru:443
* Closing connection #0
Upd:
The trouble was not on our side. The problem was hidden somewhere in w3s.webmoney.ru, in 212.158.173.158 server. I'll add more details about the bug if information will be available.
Got the following response from WM support people:
"There are four IP addresses on hostname w3s.webmoney.ru. When a request ends up on 212.158.173.158, SSL is getting killed by a piece of anti-DDoS hardware at the provider's. The problem was localized, they're now trying to fix it."
Related
I'm trying to send a POST request to a destination server via curl in PHP but it does work fine on some URL
/machines/{machineID(5digit)}/doSomething >> doesn't work
/machines/{machineID}(6digit)/doSomething >> working fine..
first I used Guzzle to made a request but It cause the same problem. So, I changed to curl. now It causes me the same problem again. but the weirdest part is If I use curl in bash. It works fine for both URLs like a charm. and It also works in Python as well. So, I don't know what happened I did some search and found this forum and I followed it already. still doesn't work. and both URLs return the same status code which is 200. It is even harder for me to debug this. is there any workaround in this situation.
Here is what I've found when I use curl -v and curl_setopt($curl, CURLOPT_VERBOSE, 1);
curl in bash (working fine)
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying xx.xx.xx.xx...
* TCP_NODELAY set
* Connected to xxxx (xx.xx.xx.xx) 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
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / xxxxx
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.xx.com
* start date: Aug 14 00:00:00 2021 GMT
* expire date: Sep 12 23:59:59 2022 GMT
* subjectAltName: host "api.xxx.com" matched cert's "*.xxx.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5649d4954600)
> POST /machines/xxxxx/dosomething HTTP/2
> Host: api.xxx.com
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Type: application/json
> x-api-key:xxx
> organization-id:xxx
> auth-token:xxx
> Content-Length: 29
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* We are completely uploaded and fine
< HTTP/2 200
< date: Tue, 21 Sep 2021 09:35:55 GMT
< content-type: application/json; charset=utf-8
< content-length: 893
< server: nginx/1.20.0
< vary: Origin
< access-control-allow-origin: *
< access-control-expose-headers: auth-token
< x-ratelimit-limit: 50
< x-ratelimit-remaining: 49
< x-ratelimit-reset: 60
< auth-token: xxx
<
* Connection #0 to host api.xxx.com left intact
{json response here}
from curl client in PHP (work only for some routes)
* Trying xx.xx.xx.xx...
* TCP_NODELAY set
* Connected to api.xx.com (xx.xx.xx.xx) 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
* SSL connection using TLSv1.2 / xxxxx
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.xx.com
* start date: Aug 14 00:00:00 2021 GMT
* expire date: Sep 12 23:59:59 2022 GMT
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x560738143210)
> POST /machines/xxxxx/doSomething HTTP/2
Host: api.xxx.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Content-Type: application/json
Accept: */*
x-api-key:xxx
organization-id:xxx
auth-token: xxxx
Content-Length: 29
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* We are completely uploaded and fine
< HTTP/2 200
< date: Wed, 22 Sep 2021 15:25:49 GMT
< content-type: application/json; charset=utf-8
< content-length: 893
< server: nginx/1.20.0
< vary: Origin
< access-control-allow-origin: *
< access-control-expose-headers: auth-token
< x-ratelimit-limit: 50
< x-ratelimit-remaining: 48
< x-ratelimit-reset: 57
< alliancels-auth-token: xxx
<
* Connection #0 to host api.xxx.com left intact
I'm trying to integrate authorize.net (AIM) using the official PHP SDK v2.0.0 and I'm seeing some strange behaviors:
curl_exec() returns false even when the request is successful and CURLOPT_RETURNTRANSFER is set to true.
curl_errno is returns 7 (Failed to connect() to host or proxy) for the same request.
I know request is successful since:
I can see the transaction is successfully recorded at authorize.net
Setting CURLOPT_RETURNTRANSFER to false causes the JSON response from authorize.net to be printed
curl_getinfo() shows HTTP status code = 200
Anyone experience this type of behavior with cURL? I'm not sure what I'm missing.
EDIT: Added output with CURLOPT_VERBOSE set
* Trying 198.241.206.22:443...
* Connected to apitest.authorize.net (198.241.206.22) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /home/app/demo/assets/lib/anet_sdk_2.0.0/lib/ssl/cert.pem
CApath: none
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=Foster City; O=Authorize.Net; CN=*.authorize.net
* start date: Feb 5 20:44:08 2020 GMT
* expire date: Mar 15 21:14:08 2021 GMT
* subjectAltName: host "apitest.authorize.net" matched cert's "*.authorize.net"
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K
* SSL certificate verify ok.
> POST /xml/v1/request.api HTTP/1.1
Host: apitest.authorize.net
Accept: */*
Content-Type: text/json
Content-Length: 1458
* upload completely sent off: 1458 out of 1458 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< X-OPNET-Transaction-Trace: a2_fe4a070f-cf07-47d7-8e9e-c8a703920de5-5628-7089051
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction
< Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET
< Access-Control-Allow-Origin: *
< Strict-Transport-Security: max-age=31536000
< X-Cnection: close
< Date: Sat, 12 Sep 2020 10:40:48 GMT
< Content-Length: 512
<
* Connection #0 to host apitest.authorize.net left intact
Good Evening Everyone.
Have been searching for a week to try and find a way of connecting using guzzle.
curl -v https://go.paytraq.com/api/{APICall}?APIToken={APIToken}&APIKey={APIKey} \
-H "Content-Type:text/xml" \
-d "{RequestBody}"
I tried all methods and keep getting unauthorised access and not sure the best way to pass APIToken and APIKey.
I have used the above from terminal and it works fine.
$client = new \GuzzleHttp\Client(['base_uri'=>'https://go.paytraq.com']);
$request = $client->request('GET','/api/clients',['debug'=>true],[ 'headers'=>
'APIToken=XXXXXX&APIKey=XXXX'
]);
The above is the last version of my code which gives me the below error
GuzzleHttp\Exception\ClientException
Client error: GET https://go.paytraq.com/api/clients resulted in a 401 Unauthorized response: API key or token is not provided
And below is the guzzle debug
Trying 52.16.7.7:443... * Connected to go.paytraq.com (52.16.7.7) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /usr/local/etc/openssl#1.1/cert.pem CApath: /usr/local/etc/openssl#1.1/certs * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: CN=go.paytraq.com * start date: Oct 14 00:00:00 2019 GMT * expire date: Nov 14 12:00:00 2020 GMT * subjectAltName: host "go.paytraq.com" matched cert's "go.paytraq.com" * issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * SSL certificate verify ok. > GET /api/clients HTTP/1.1 Host: go.paytraq.com User-Agent: GuzzleHttp/7 * Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized < Content-Type: text/plain; charset=utf-8 < Date: Sat, 01 Aug 2020 21:03:49 GMT < Request-Time: 1 < Server: nginx/1.4.6 (Ubuntu) < Content-Length: 32 < Connection: keep-alive < * Connection #0 to host go.paytraq.com left intact
This should work:
$client->request('GET', '/api/clients', ['query' => [
'APIToken' => $APIToken,
'APIKey' => $APIkey]
]);
A client had their server moved and the magento cron.php was never set back up. When I enabled them, I found that Magento was posting to paypal:
Cron /usr/bin/php -q /home/dev/public_html/cron.php
* About to connect() to api-3t.paypal.com port 443 (#0)
* Trying 173.0.88.69...
* connected
* Connected to api-3t.paypal.com (173.0.88.69) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using DES-CBC3-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api-3t.paypal.com
* start date: 2013-07-03 00:00:00 GMT
* expire date: 2015-09-18 23:59:59 GMT
* subjectAltName: api-3t.paypal.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
> POST /nvp HTTP/1.1
Host: api-3t.paypal.com
Accept: */*
Content-Length: 225
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 225 out of 225 bytes
< HTTP/1.1 200 OK
< Date: Tue, 25 Mar 2014 01:45:04 GMT
< Server: Apache
< Content-Length: 240
< Connection: close
< Content-Type: text/plain; charset=utf-8
<
* Closing connection #0
There were a bunch of these that were output from the cron job. I immediately disabled the cron.
I can’t, for the life of me, find:
1: any reason for magento to contact paypal (this is a dev server that hasn’t had a complete order since it was set up [from copy of the production server])
2: any logs in Magento or Payal that could tell me what exactly it’s posting.
Can anyone shed some light? We really need to get the cron working so we can get the sitemap generation running but I am not comfortable having it talk to Paypal for no reason.
We currently are using Paypal Payments Pro and Express Checkout
Thanks,
Mike
This is standard Magento cron job for getting reports from paypal, no worries. You are right - it's paypal_fetch_settlement_reports job. It placed in app/code/core/Mage/Paypal/etc/config.xml:
<crontab>
<jobs>
<paypal_fetch_settlement_reports>
<run>
<model>paypal/observer::fetchReports</model>
</run>
</paypal_fetch_settlement_reports>
</jobs>
</crontab>
I originally posted this at the Amazon SES forums here: https://forums.aws.amazon.com/thread.jspa?threadID=74561&tstart=0
But since the stackoverflow community is more active, I'll post it here :)
Basically I have a forecah loop around a cURL post (see bottom of post for script snippet). It works for a couple hundred posts, but then starts to fail for all the others. Here's the last successful post followed by the first of 100's of unsuccessful posts...
* About to connect() to email.us-east-1.amazonaws.com port 443 (#0)
* Trying 207.171.162.2... * connected
* Connected to email.us-east-1.amazonaws.com (207.171.162.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: email.us-east-1.amazonaws.com matched
* issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
POST / HTTP/1.1
Accept: */*
Host: email.us-east-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
Date: Sat, 20 Aug 2011 18:59:56 UTC
X-Amzn-Authorization: AWS3-HTTPS AWSAccessKeyId=LKIABMH7PT8SO4YBRDQA,Algorithm=HmacSHA1,Signature=/0HFVEsTBGqUUSQGy9jvmsft2k4=
Content-Length: 5810
Expect: 100-continue
< HTTP/1.1 200 OK
< x-amzn-RequestId: 4a0f8f18-cb5f-11e0-8364-b14fdafc0888
< Content-Type: text/xml
< Content-Length: 326
< Date: Sat, 20 Aug 2011 19:04:55 GMT
<
* Connection #0 to host email.us-east-1.amazonaws.com left intact
* Closing connection #0
The the failures start....
* About to connect() to email.us-east-1.amazonaws.com port 443 (#0)
* Trying 207.171.162.2... * connected
* Connected to email.us-east-1.amazonaws.com (207.171.162.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: email.us-east-1.amazonaws.com matched
* issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
POST / HTTP/1.1
Accept: */*
Host: email.us-east-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
Date: Sat, 20 Aug 2011 18:59:56 UTC
X-Amzn-Authorization: AWS3-HTTPS AWSAccessKeyId=LKIABMH7PT8SO4YBRDQA,Algorithm=HmacSHA1,Signature=/0HFVEsTBGqUUSQGy9jvmsft2k4=
Content-Length: 5806
Expect: 100-continue
< HTTP/1.1 400 Bad Request
< x-amzn-RequestId: 4b8f29db-cb5f-11e0-b9af-33e5c8fc863b
< Content-Type: text/xml
< Content-Length: 347
< Date: Sat, 20 Aug 2011 19:04:58 GMT
<
* Connection #0 to host email.us-east-1.amazonaws.com left intact
* Closing connection #0
Here's the script snippet
foreach($JSONarray['DATABASE'] as $E)
{
if ((array_diff($E['LISTS'], $FILTER) != $E['LISTS']) && $E['STATUS'] == "CONF")
{
$MAIL = "Action=SendEmail&Source=".$FROME."&ReturnPath=".$BOUNCE."&Destination.ToAddresses.member.1=".$TOE."&Message.Subject.Data=".$SUBE."&Message.Body.Html.Data=".$BODYE;
//curl
$aws = curl_init();
curl_setopt($aws, CURLOPT_POSTFIELDS, $MAIL);
curl_setopt($aws, CURLOPT_HTTPHEADER, $headers);
curl_setopt($aws, CURLOPT_HEADER, false);
curl_setopt($aws, CURLOPT_URL, $url);
curl_setopt($aws, CURLOPT_RETURNTRANSFER, true);
curl_setopt($aws, CURLOPT_VERBOSE, true);
curl_setopt($aws, CURLOPT_STDERR, $SESLOG);
curl_exec($aws);
curl_close($aws);
}
}
Any ideas?
Could it be a DOS prevention mecanism kicking in? How about putting some sleeps into your code? I would definitely put some safeguards against potential DOS attacks if I were Amazon..
Just a guess, though...
I figured out the problem:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>RequestExpired</Code>
<Message>Request timestamp: Mon, 22 Aug 2011 15:49:11 UTC expired. It must be within 300 secs/ of server time.</Message>
</Error>
<RequestId>0e3899cb-ccd7-11e0-9f09-c5d12d442026</RequestId>
</ErrorResponse>
My headers were set-up outside the forecah loop around curl. Doh! So I just moved that bit of code into the loop to solve the time-out problem.