I have noticed that my server-side receipt validation code is failing only for the sandbox (the live version of my app in the store works fine, but on Xcode, where I am testing the next version, receipt validation always fails).
I tracked the problem to the php/curl code where I contact the iTunes server (https://sandbox.itunes.apple.com/verifyReceipt), and I get this error from curl:
SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:func(144):reason(134)
I wonder if this has anything to do with the russian guy and his hack...
But it only happens with my sandbox code. The live version seems to be working...
Any clues?
Perhaps I should use the 'live' iTunes server for both sandbox and live, as detailed here?
in app purchase, production receipt validation now validating sandbox purchases?
(Wasn't aware of this change. Is it still OK?)
EDIT I modified my sandbox-php code to use the LIVE iTunes server (URL: https://buy.itunes.apple.com/verifyReceipt), and test-user purchases/repurchases are working now. I am still puzzled... Has the sandbox server been deprecated? Does it identify itself with an SSL certificate different than the live environment, which certificate has been revoked?
Looks like Apple recently reupped the SSL cert for Sandbox and it is signed correctly with the subject alternate name domain sandbox.itunes.apple.com. but didn't sign it with the correct URL (or just used the one from Live and not bothered with Sandbox). They instead signed it with buy.itunes.apple.com which broke any cURL requests (our server had the same problem). As a workaround for now, we have used the option:
if ($isSandbox) curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
This turns off SSL verification, so use with caution as it could lead to man-in-the-middle attacks. I don't think this is a huge deal on Sandbox since it is test users in a test environment.
Edit:
Actually, Apple pointed out that the CA cert bundle with a default cURL install prior to 7.18.0 is severely outdated. http://curl.haxx.se/docs/sslcerts.html
We may have had a server update recently that broke our cURL installation, but I'm not our Sys Admin so I really don't know for sure. But take a look at the link as that includes the workaround I mentioned above (#1), and a few other options, including updating the CA cert bundle.
Edit:
I wanted to add another side-note here. It seems as though there was a bug fix in cURL version 7.19.7 that dealt with Subject Alternative Names.
libcurl-OpenSSL failed to verify some certs with Subject Alternative Name
So this could in fact be partially Apple, and partially cURL. Apple's certificate renewal with the usage of the SAN possibly broke anything still on any version older than 7.19.7. We are still testing as to whether this is the case on our server.
Edit:
We found out that the issue was not the version of cURL we were using, but it was with the CA cert pem file we needed cURL to point to. It is #2 via the cURL link above, but in PHP it looks like this:
if ($isSandbox) curl_setopt($ch, CURLOPT_CAINFO, '/etc/ssl/certs/cacert.pem');
You can grab the latest CA cert pem file from http://curl.haxx.se/docs/caextract.html
Related
I have installed and followed all the step in creating an using Openssl but when I open localhost as https the browser says the connection is not secure or brings out privacy.
Kindly let me know what am doing wrong? How can one make it https and bring the green lock?
You did everything right but the browser doesn't know your certificate.
The browser will warn you everytime he gets a certificate signed by an authority he doesn't know. That DOESN'T mean that you did something wrong.
You can add your certificate as trustworthy (i.e. add an exception for your specific certificate) in the browser and everything will function as it would with a certificate from a trusted certificate authority (e.g. Comodo, RapidSSL, Symantec, etc)
I am doing a CAS integration with a project that I am doing with my university. The final integration should be made with symfony2, however first I need to make the example code working.
I finally get working the example_simple.php example with phpCAS 1.3.2 , however the directive:
phpCAS::setNoCasServerValidation();
is the enabled one. I think I should use instead:
phpCAS::setCasServerCACert($cas_server_ca_cert_path);
However when I enable this second one (and disable the other) then the authorization does not work anymore. Here is the relevant output line error of the log:
could not open URL 'https://cas_server.fi/cas/serviceValidate?service=http%3A%2F%2Flocalhost%2Fphpcas2%2Fdocs%2Fexamples%2Fexample_simple.php&ticket=ST-115606-M1Omd1cHWzbLbmxa1nYV-cas' to validate (CURL error #60: SSL certificate problem: unable to get local issuer certificate) [Client.php:2763]
The cas server provided me two .crt files:
MYCASRootCA.crt
MYCASLinuxSUBCA.crt
And they are suppose to be installed in my system (Ubuntu 13.10). They are in different places, such a /etc/ssl/certs/MYCASLinuxSUBCA.pem but also:
/usr/share/ca-certificates/lut/MYCASRootCA.crt
/usr/share/ca-certificates/lut/MYCASLinuxSUBCA.crt
So assuming that the variable $cas_server_ca_cert_path has to have one of these .crt files or .pem dirs (such a /usr/share/ca-certificates/lut/MYCASLinuxSUBCA.crt) I cannot make it work. What I am doing it wrong? My client-server (no the cas server) is in my localhost. Is it a problem? Should I avoid use setCasServerCACert command? Why is it happening?
I've also tried to use the curl-ca-bundle.crt certificate provided by my XAMP instalation (Xampp 1.8.3).
I am a little bit lost with certificates as you can see.
I read about problems with phpCAS and recent Ubuntu versions in https://github.com/Jasig/phpCAS/issues?state=open. However I cannot make this working with the master code, even without certification (by default).
Any ideas would be appreciated...
I have found the solution asking in the github library: https://github.com/Jasig/phpCAS/issues/119
The reason is that the curl binary used by PHP in my xampp installation is different from the system's curl binary. The system one has access to /etc/ssl/certs/ certificates, but the xampp curl does not have (unless you don't indicate it, of course). By default, it searches in a special certificate-bundle-file.
Finally I have found the real certificate for my cas-server and I am using it, however maybe you want to use other proposed solution at the end of the discussion thread if you are having a similar problem.
I'm in the midst of integrating PayPal into my website. At this stage, I am using the PayPal Sandbox along with the Instant Payment Notification (IPN) simulator. For the listener itself, I'm using Micah Carrick's code. When sending an IPN through the sandbox, I received the follow error:
cURL error: [77] Problem with the SSL CA cert (path? access rights?)
I originally thought the problem was that my website lacked a SSL certificate, so I purchased one and installed it. Unfortunately, that did not solve my problem. After doing some more research I am under the impression that I am missing a certificate file from PayPal or from cURL. I downloaded one of the developer bundles (pp_php_soap_sdk_1) from PayPal and copied the api_cert_chain file into the directory of my ipn code, but that was unsuccessful. When looking at the certificate, it appears to be expired, so perhaps that is the problem. Any ideas?
Feel like an idiot, but the problem stemmed from the location I was storing the SSL CA cert.
The file ipn_listener.php points to a file called "api_cert_chain.crt". You're most likely missing it. You can download it from: https://cms.paypal.com/cms_content/US/en_US/files/developer/PP_PHP_SOAP_SDK.zip
Download and extract the zip. The file "api_cert_chain.crt" is located in the folder: PP_PHP_SOAP_SDK/php-sdk/lib/PayPal/cert. Upload the file to the directory /cert/ on your server (might need to create the folder).
I came across the solution from this website (last post): Webmaster World.
In the "ipn_listener.php" file there is code that points to the api_cert_chain.crt
dirname(__FILE__)."/api_cert_chain.crt");
You need to make sure that the path to that .crt is actually pointing to where the .crt is on your webserver.
I'm working on an open source PHP application. The application may need to connect to my server, to transfer sensitive data. I have SSL installed on my server and I think I have set it up properly, but I'm hoping someone here can confirm.
The application will be used on other users servers, so it will be server to server communication.
I will treat users servers as clients when connecting to my server. My server will never connect to their server, so they don't need SSL on their end (right?).
I use cURL to make the calls (to my server) and POST data during the connection. So I cURL to a https address.
Now I thought that is it. Once I cURL a https address, everything is secure. I can send whatever I like (Credit card numbers, passwords, etc etc) securely, without worrying about the middle man. End of story.
But after reading around, I've noticed that some people are doing other stuff in their cURL session - Like including a certificate (.crt file):
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_CAINFO, getcwd() . "/CAcerts/BuiltinObjectToken-EquifaxSecureCA.crt");
Is that safe for open source? Should I do it too? Or am I safe with what I've got?
Depending on the system you're installing cURL on, it may or may not have enough information to verify an SSL certificate (this can be improved by linking intermediate and root certificates into your website certificate). You can also read it here: http://curl.haxx.se/docs/sslcerts.html
It sometimes makes sense to ship a bundle explicitly, especially since cURL tends to get shipped with old certificate bundles. You can download a more recent one here (which is taken from the Firefox source code): http://curl.haxx.se/docs/caextract.html
If your software will exclusively talk to your own server, you could also ship a bundle containing only your own public certificate. This would allow you to use self signed certificates which is free :)
You attach your client certificate along CURL calls if the server at the other end has specifically provided you with them and are not accepting any connection from other clients than the ones who have those client certificates.
If you are talking about a website here, you dont even need to worry about that here.
But if you are talking about some service providers which you access for any secured resources, and if they require you to produce client certificates, they will issue them for you and tell you explicitely to use them.
For an example, we have a system which only private members can access. We have an RPC endpoint where other members send request to. And since we only allow access to our members (private NOT public like websites) we issue them client certificates and explicitely direct them to attach those along with their service calls.
I was wondering if any of you know if it is possible in javascript or php to test if a client has a specific client certificate installed in the browser.
The thing is that we have a server certificate installed but to be recognized by the clients, they need 2 client certificates that make them recognize the authority of the issuer of our server certificate. We would like to test the browser for these 2 certificates, if there are not there, we want to propose the client to download them before to enter in https mode...
Anybody can help? Please detail your answer if you know one.
You can do it client side by using javascript to request a known file from a secured (https) source. if the request fails then it means the client refused to accept your certificate (or another network error) at this point you could popup a message to ask the user to install the root certificate with a link to the root certificate.
This must be done from a non secure page. otherwise the user may refuse your certificate and never load the page to start with and therefore your javascript never runs
It can't be done in PHP because php (which is server side) cannot determine whether the client browser has a particular root ca installed
I however would not do this. get a proper certificate instead.
You appear to have insufficient understanding of how SSL works in general. I suggest spending some time understanding how SSL works and how certificates are used.
DC
to learn about sending and receiving http responses with javascript read this page..
http://www.w3schools.com/XML/xml_http.asp
It can be used to send and receive any text data, not just xml. It is real easy to implement but you must be aware of browser version issues.
DC
what about a warning message that will be hidden by a javascript which will be loaded from your https site.
in the warning message you can link the windows update site or wherever the updated root certifcates can be downloaded to their browser.
PHP is a server side language. If you really want to test this then you need to do it with JavaScript and then send back an AJAX request to PHP.
But I think there is another solution to your problem. Normally when a CA change their name etc. they have usually new "Intermediate Certificates" you can use. (If you have an apache httpd server then you can search for "ca bundle" on their website as well.) With this bundle you can send the new CA certificate along with your certificate.
Forcing your users to download and install a homegrown CA certificate is ugly and hateful. Instead, show them the love and pay the $30 US to get an SSL certificate signed by a reputable, already trusted, CA.