I am using paypal merchant sdk and my curl version goes as
[version_number] => 463623
[age] => 3
[features] => 1597
[ssl_version_number] => 0
[version] => 7.19.7
[host] => x86_64-redhat-linux-gnu
[ssl_version] => NSS/3.14.0.0
[libz_version] => 1.2.3
[protocols] => Array
Because of NSS I am getting error Unknown cipher in list: TLSv1
Many posts suggest making changes to pphttpconfig.php file and remove option CURLOPT_SSL_CIPHER_LIST => 'TLSv1' , do I have any other option which can be used because since I am using composer chaces are there that library get updated and my changes gets overwritten.So how can I make sure that my integration works fine
Possible Duplicate
Paypal SDK Adaptive Payments Unknown cipher in list: TLSv1
I have been working on REST API SDK, which had a similar issue as you are facing. I was able to make the change there, but I didnt get time to fix this. If you feel, you could send me a quick pull request, with pretty much the same fix as the REST one, and I would be more than happy to accept it.
Related
An email from Amazon AWS states:
Beginning October 1st, 2020, Amazon SES will only support requests
signed using Signature Version 4.
You can easily identify API requests that use Signature Version 3 by
looking at the request headers. Requests that use the Signature
Version 3 resemble the following example: X-Amzn-Authorization:
AWS3-HTTPS
AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE,Algorithm=HMACSHA256,Signature=lBP67vCvGl
...
I have got "aws/aws-sdk-php" installed through composer.
I'm trying to find out if the request header of SES is Signature Version 3 or 4.
I tried dumping the content of Illuminate\Mail\Events\MessageSent through $event->message->getHeader() which is a Swift_Mime_SimpleHeaderSet Object.
Yet it doesn't include the request version to the SES sdk.
QUESTION:
Could someone please tell me how to dump the outgoing aws ses sdk request so I can see in the header what version is used.
Thank you.
If anyone is interested, finally was able to do it by back tracing the stack.
After sending a mail through a command, I back traced the stack and could see the raw request, which included Authorization: AWS4-HMAC-SHA25, confirming Signature Version 4.
Mail::to($receiver)->send($mailable);
dump(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 50));
Make sure that you have the ses service debug set to true:
config/services.php
'ses' => [
'key' => env('SES_KEY'),
'secret' => env('SES_SECRET'),
'region' => 'us-west-1',
'debug' => true,
],
I am the SP, I can not loggedin into the SP using IDP of my client,
I got below error:
SimpleSAML_Error_Error: ACSPARAMS
Backtrace:
1 modules/saml/www/sp/saml2-acs.php:21 (require)
0 www/module.php:135 (N/A)
Caused by: Exception: Unable to find the current binding.
Backtrace:
2 vendor/simplesamlphp/saml2/src/SAML2/Binding.php:99 (SAML2\Binding::getCurrentBinding)
1 modules/saml/www/sp/saml2-acs.php:16 (require)
0 www/module.php:135 (N/A)
My Configuration for authsource.php is like below:
'abc-live-sp' => array(
'saml:SP',
'privatekey' => 'saml.pem',
'certificate' => 'saml.crt',
'entityID' => null,
'idp' => 'https://federation-a.parnassiagroep.nl/superbrains',
'discoURL' => null,
'NameIDPolicy' => false,
),
Is there anything i am missing?
help will be appreciated.
The exception trace is as below.
In config.php, allow HTTP POST requests. This worked for me.
'enable.http_post' => true
In addition, I restricted ACS URL binding to HTTP-POST. This may not be necessary.
'acs.Bindings' => array( 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST').
I still don't know why the ACS URL and other URLs in the metadata are coming as HTTP links, All the links in the config files are HTTPS.
Did you setup the Identity Provider in your "metadata/saml20-idp-remote.php" file?
It's been a while since I used simplesamlphp but I'm pretty sure you would need to have the Identity Provider (IdP) administrator add you as an "accepted" Service Provider (SP). This is done by sharing your metadata with them.
There is a very handy guide by UNINETT, the creators of simplesamlphp here:
https://simplesamlphp.org/docs/stable/simplesamlphp-sp
Someone also had a similar issue:
Simplesamlphp unhandled exception error while using as SP
I am using Paypal API Code integration in my project. It is working fine while using Sandbox credentials. Getting error while using Live credentials. Changed Url sandbox to Live. copied exact username, password & signature by using notepad. Still i am getting the same eoor. Can you please tell me if any changes i have to do. Searched in google but not succeded.
tested in multiple servers. getting same error in both servers.
Error : Security header is not valid
Array
(
[TIMESTAMP] => 2014%2d05%2d01T21%3a22%3a22Z
[CORRELATIONID] => da5fb2a0d16b7
[ACK] => Failure
[VERSION] => 76%2e0
[BUILD] => 10800277
[L_ERRORCODE0] => 10002
[L_SHORTMESSAGE0] => Security%20error
[L_LONGMESSAGE0] => Security%20header%20is%20not%20valid
[L_SEVERITYCODE0] => Error
)
Make certain to use your Live PayPal Account Credentials and point all of your endpoints at the live PayPal Server.
User Name:
Password:
Signature:
If you attempt to use your sandbox credentials with a live endpoint you will get security header errors.
I have seen this happen simply because of the credentials not matching with the endpoint.
Here is the going live documentation from the PayPal Developer site:
Going Live PayPal API Developer Documentation
Here is a listing of PayPal Endpoints:
PayPal Endpoints
How can I force TLSv1.0 in a PHP stream context when trying to access an https URL?
I’m looking for something along the lines of this:
$context = stream_context_create(
array(
'ssl' => array(
'protocol_version' => 'tls1',
),
));
file_get_contents('https://example.com/test', false, $context);
Background
Actually I’m facing an issue in Ubuntu 12.04 when working with PHP’s SoapClient. Unfortunately, the server I’m trying to connect to does only support SSLv3.0/TLSv1.0 and fails on the default TLSv1.1 negotiation. Therefore I’d like to explicitly set the protocol of the ssl:// transport to TLSv1.0.
PHP 5.6+ Users
This is a new feature as documented on the PHP 5.6 OpenSSL Changes page.
At time of writing this, PHP5.6 is in Beta1 and thus this isn't overly useful. People of the future - lucky you!
The future is upon us. PHP 5.6 is a thing and its use should be encouraged. Be aware that it deprecates some fairly widely used things like mysql_* functions so care should be taken when upgrading.
Everyone else
#toubsen is correct in his answer - this isn't directly possible. To elaborate on his suggested workarounds... when working around a problem where a supplier's API server wasn't correctly negotiating TLSv1.2 down to its supported TLSv1.0, sending a small subset of ciphers seemed to allow negotiation to complete correctly. Stream context code is:
$context = stream_context_create(
[
'ssl' => [
'ciphers' => 'DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:KRB5-DES-CBC3-MD5:KRB5-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:KRB5-DES-CBC-MD5:KRB5-DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-KRB5-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-RC4-MD5:EXP-RC4-MD5',
],
]
);
SOAP Users
PHP's SOAP client doesn't use curl, nor does it seem to use the default context set with stream_context_set_default. As such, the created context needs to be passed to the SOAPClient constructor in the 2nd parameter as such:
$soap_client = new SOAPClient('http://webservices.site.com/wsdlfile.wsdl', array('stream_context' => $context));
Why those Ciphers?
Running the command openssl ciphers on the server gives you a list of supported ciphers in the above format. Running openssl ciphers -v tells you those that are TLSv1.2 specific. The above list was compiled from all of the non-TLSv1.2 ciphers reported by OpenSSL.
openssl ciphers -v | grep -v 'TLSv1.2' | cut -d ' ' -f 1 | tr "\n" ':'
In case someone wants to know how to "disable" TLSv1.0 when making a SOAP request...
$parameters = array(
'trace' => true,
'exceptions' => true,
'cache_wsdl' => WSDL_CACHE_NONE,
'stream_context' => stream_context_create(array(
'ssl' => array(
'ciphers' => 'DEFAULT:!TLSv1.0:!SSLv3'
),
)),
'connection_timeout' => 15
);
$client = new SoapClient(YOUR_WSDL_URL_HERE, $parameters);
The key part here is that stream context ciphers line. This says use the default ciphers, but exclude TLSv1.0 ciphers (the 1.0 package also has TLSv1.1 ciphers). The : is the cipher package separator (what goes between packages) and the ! here is to tell it to exclude this package (it's a hard exclude so if it shows up later in the list it will still be excluded). Soft exclude is - character and add to the end of the list is + character. To add in order just add it without anything in front of it.
Cipher information here: https://www.openssl.org/docs/manmaster/man1/ciphers.html#CIPHER-LIST-FORMAT
Edit:
For whatever reason including the
'ssl_method' => SOAP_SSL_METHOD_TLS,
part from the options was really causing me headaches and wouldn't connect in certain contexts. After tons of troubleshooting and playing around with options I finally realized that removing this setting and letting it autoset this seems to have resolved the issue.
Base information
The field protocol_version is only valid for HTTP context (HTTP 1.0 vs 1.1), but does not affect the SSL context.
The following manual page lists all stream context options for PHP:
Context options and parameters
For all SSL based stream wrappers, only the follwing options are available:
SSL context options
Possible solutions / workarounds
First advice: Get the server admin to fix his server instead of working around this in your client ;-)
Maybe you can get it wo work with the ciphers option for SSL streams, to pass only one exact TLSv1.0 cipher suite (that is unique to TLSv1.0) in the list, that your target server supports.
Switching the implementaion to use cURL will most probaly also not help here, as according to an entry in their mailing list, there's no option to force a certain TLS version - the client will downgrade when needed automatically.
tl;dr
I currently know of no way to explicitly force TLSv1.0 for SSL connections from PHP.
I can confirm that above accepted answer does not work for Ubuntu 12.04 and PHP 5.4.33 combination. Also found out that I have to manually specify certificate when trying openssl and curl to access https endpoints. I ended up using RHEL 7 and PHP 5.5 to achieve a solid solution as I was developing integration for an enterprise application. Nothing against Ubuntu, but in my specific case it didn't work.
I was playing around the new swiftmailer 4.0.4 using my zend studio embbeded apache server where i can send successfully emails through gmail smtp.
Now that it's was fine and that i decided to use it in real project and this time along using xampp 1.6.8.any time i run the same function there is this error
Warning: fsockopen() [function.fsockopen]: unable to connect to ssl://smtp.gmail.com:465 (Unable to find the socket transport "ssl" - did you forget to enable it when you configured PHP?) in C:\xampp\htdocs\project\includes\swift\classes\Swift\Transport\StreamBuffer.php on line 243
i've tried to enable ssl from xampp index file it has accepter the certificate but still my error won't disapear.I'm really concerned about this.Can anyone share his opinion or experience? thanks for reading!
The problem is that you don't have the ssl transport installed for php. Different systems do this in different ways, so I don't know how yours would work.
You can run a quick php app to verify this:
<?php
print_r(stream_get_transports());
Mine returns:
Array
(
[0] => tcp
[1] => udp
[2] => unix
[3] => udg
[4] => ssl
[5] => sslv3
[6] => sslv2
[7] => tls
)
If ssl and tls are not there, then your php installation does not have support for them and you need to find a way to fix that.
i think for some reason it started working.i'm not sure about what happened,i reinstall xampp and didn't see the problem anymore.weird.