Hello, how can I make sure I will not have issues when the certificate change is done? I use https connection from a Windows desktop app (.NET framework). I guess I shouldn't have problem, but is there a development environment to test?
We are planning to open some test windows in the next weeks, I'll publish in this thread soon.
As an alternative, userstream.twitter.com certificate was updated in beginning of November and it's using the same certificate that will be deployed in REST API. You can send a HEAD request to User streaming endpoint to check if your are already trusting the right certificates. If this is not the ideal test environment for you, please, subscribe to this thread to know when we are going to open the test window.
Confirming that tomorrow (Dec 3rd), from 11:30am to 1pm PST, the servers at api.twitter.com will have the new certificate deployed. After this period a rollback will be done. This is a great opportunity to check if your application is trusting the new certificates that will be permanently deployed in Dec 10th, 2013 (see REST API SSL certificate updates)
If your application gets impacted by this test, the action required is to include the new root certificates in your servers and make sure all HTTP clients are aware of them.
Please, also make sure you have certificate verification always enabled when using Twitter APIs.
The rollback started at 1pm PST and it can take up to one hour to affect all servers. So it's expected to still have issues after this period if your app isn't trusting the new certificates.
Has the certificate been installed? Some of my requests work others do not. Also when going to api.twitter.com I sometimes get the old version and sometimes the new one. I noticed to that the newer certificate only started showing for me an hour later 11:30am PST.
We have seen a new problem on two different sites that is preventing twitter app login using the API since around 20:30 UTC on the 3rd (about 2.5 hrs ago).
We have tested other aspects of the API, and they seem to work just fine (tweet, retweet, favouriting etc).
It is just the last step to get the access token after the callback to 'finalize' that's is failing, we get a 403. This has been tested also on multiple hosts, as well as with the different apps with the same result. Also both hosts have the correct time set.
FWIW, using curl it seems we are still getting the new certificate coming through :
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
Thanks for the details John, this looks like an unrelated but similarly timed issue. While definitely you should be using SSL on these methods, the enforcement shouldn't be occurring right now. I'll see what's up.
OK, yes, seems some old code that was working up to today is now not working.
Found a single old reference to a http:// endpoint in our code that had been working just fine up until today, changed it to https:// and all is working again.
So if you're seeing issues, look for any remaining non SSL references in your code as these appear to have been only finally fully deprecated today.
hello, I downloaded the root package for VeriSign Certificates (roots.zip file)
and then what should I do?
I'm using centos5 and php
My problem is
1. I don't know how to update VeriSign Certificates on my server. I'm using CentOS.5.xx
I found this /etc/pki/tls/certs/ca-bundle.crt
2. I couldn't find -3 option in curl commands..
curl -3 -capath --ssl https://api.twitter.com
and -capath means /etc/pki/tls/certs/ca-bundle.crt ??
3. I looked up EpiCurl.php that I'm using but I couldn't find the place where I can put these
1.curl_setopt($connection, CURLOPT_SSL_VERIFYPEER, True);
2.curl_setopt($connection, CURLOPT_SSL_VERIFYHOST, 2);
3.curl_setopt($connection, CURLOPT_CAINFO, "path:/ca-bundle.crt");
There's no need to change the library you're using, in PHP there's a global configuration you can change (for PHP 5.3.7 or superior):
1) download http://curl.haxx.se/ca/cacert.pem and save it somewhere. (this pem file already has Verisign root needed for api.twitter.com)
2) update php.ini -- add curl.cainfo = "PATH_TO/cacert.pem"
Otherwise you will need to do the following for every cURL resource:
I followed the 1, 2 and restarted Apache
and added CURLOPT_CAINFO like this but it doesn't work yet...
protected function curlInit($url)
{
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, $this->headers);
curl_setopt($ch, CURLOPT_TIMEOUT, $this->requestTimeout);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $this->connectionTimeout);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
if(isset($_SERVER ['SERVER_ADDR']) && !empty($_SERVER['SERVER_ADDR']) && $_SERVER['SERVER_ADDR'] != '127.0.0.1')
curl_setopt($ch, CURLOPT_INTERFACE, $_SERVER ['SERVER_ADDR']);
Has anyone successfully done this with ColdFusion? The cfhttp tag in ColdFusion 9 does not work with the new certificate. I've imported the .cer and .pem files for the "VeriSign Class 3 Public Primary CA - G3" version, and the ColdFusion keystore utility indicated the imports were successful. But I'm still not able to connect to the API (it worked perfectly before the new certificate). Thanks!
Same problems with CF8 and Monkeh Tweet. Until I can work out the new SSL certificate issues, I just changed the api endpoints in base.cfc to use http instead of https. Not ideal, but it'll work for now, and it'll save me yet another frustrating day of attempting to debug this issue.
Unfortunately, CF 9 Enterprise w/Monkeh isn't working since Twitter changed their SSL certs. If anyone figures out how to get CF9 to see these new certs, please post. I haven't been trying very long but so far I've had zero luck.
Since I couldn't get the cacerts changes to work in ColdFusion 9 Ent and am out of time, I just changed base.cfc in MonkehTweet to use http instead of https and my application is at least useable for the time being. Thanks for the tip @beercodebeer.
If anyone here can get these new certs to work with CFHTTP, please post your solution. Thanks!
-JD
I was able to resolve the MonkehTweet Twitter SSL certificate issue by upgrading ColdFusion 9.01 Standard to use JDK 1.7 which includes the required certificates. In order to do this, I first installed the 9.02 Cumulative Hotfix 1 on 9.01. Follow the instructions at: http://helpx.adobe.com/coldfusion/kb/cumulative-hotfix-1-coldfusion-902.html
I'm not sure if the hotfix is required to use JDK 1.7 on 9.01 but it worked for me. I could not upgrade to 9.02 as is does not include Verity support which I needed. Once the JDK upgrade was complete, I was good to go without any further fussing with certificates. This was successful on three different servers.
Have successfully got ColdFusion 8 to connect to the twitter API with the new certificates. Note that is isn't just once certificate you need to add to trustStore, but TWO:
Generation 3 (G3) PCAs - RSA2048/SHA1 - VeriSign Class 3 Public Primary Certification Authority - G3
Generation 5 (G5) PCA - RSA2048/SHA1 - VeriSign Class 3 Public Primary Certification Authority - G5
A few of the servers that I manage are running ColdFusion 9 Enterprise multi server. When Twitter updated their SSL certificates on December 10th, 2013 (I believe that's the date) my applications that use monkehTweet stopped working and couldn't connect to Twitter using CFHTTP.
After adding the following certs to my cacerts file using the keytool utility in C:\JRun4\jre\bin, I finally have it working in CF 9 Enterprise!
Download each of the certs above and save them to C:\JRun4\jre\lib\security (or wherever you'd like, just change the paths in the keytool commands below)
Open a Windows CMD prompt and change directories to C:\JRun4\jre\bin
Run the following keytool commands to add the required certs to you cacerts file
(these commands assume you are using the default password: changeit)
Thank you and @seajays for this, the problem we were having is that we didn't have Class 3 G5 in our cacerts file. Added them and restarted, now it's working like a charm.
So after trying nearly everything I could think of, I finally got it working. Here are the steps I took to resolve the issue on ColdFusion 8 Standard with monkehtweet.
First, I went to https://api.twitter.com in Firefox. Once there, I went to Tools -> Page Info. On the Security tab, I clicked View Certificate, then clicked the Details tab, then Export and saved the file as a .cer file (api.twitter.com.cer). I then copied this file to c:\cert on my CF8 dev box.
I then remoted in to my dev box and ran a command prompt. I had to right-click on the shortcut and select 'Run as Administrator' in order for this to work properly.
I then changed to the directory where keytool resides - c:\coldfusion8\runtime\jre\bin\ - and ran the following command: keytool -import-v -alias twitter-cert -file c:\cert\api.twitter.com.cer-keystore c:\coldfusion8\runtime\jre\lib\security\cacerts -storepass changeit
I restarted CF8 Application Server and ran my test page that makes an https call to the Twitter api, and finally received a successful result (rather than the dreaded "Connection Failure" message).
For posterity, here are some things that did NOT work for me.
Following guidance from here (https://dev.twitter.com/blog/rest-api-ssl-certificate-updates), where Twitter mentions the impending SSL update, I went to the Symantec page and downloaded/installed the Class 3 Gen 3 certificates. However, when importing them, I was told they already existed in the keystore. I went ahead and overwrote the existing keys, but that was no help. Eventually, I resorted to downloading and resinstalling ALL of their public certificates. Most were already present, some were not, and one gave me an error. But even this had no effect. This was on a separate dev box than the one I'm referring to above, by the way, so I know that it was not a combination of things that led to a successful resolution, but rather just the cert from api.twitter.com.
@beercodebeer -- Do you know if something has just changed to make this not work? This approach worked perfectly until yesterday, when I started getting the dreaded connection failure again...
Hi @ckryanco. I did have to repeat this process recently. It looks like Twitter recently updated their SSLs again (probably related to the Heartbleed bug), but following the steps above resolved the recurring Connection Failure error for me.
I expected the new Java versions to already have these new Verisign CA certs and for the most part they do. I am working on this issue for a client and I have been testing with a dev setup that has both CF8.0.1 and CF10 installed. Both CF versions are using the same Java install and cacerts file. CF10 works and CF8 does not. Even another setup with CF9 is working. The JVM version in play here is 1.6.0_45. For those with an older JVM installed an upgrade of the JVM may be all you need if running CF9. And CF9 will run on JVM 1.7.0_nn once you fully patch CF9. I'm wondering if those that have this working on CF8 have forgotten they had switched to http instead of https before hand?
Hi all, I developed an IoT device which is build around a small micro controller and the .NET micro framework.. The device was able to send out tweets using API 1.0 Software in the device used direct socket programming to communicate with the API. The new API requires SSL and requires a lot of extra software in the device and will adds a performance penalty. Is a secure connection really needed also from small embedded devices to use the current API?
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Relevant discussions can be found on the Internet at: http://www.google.co.jp/search?q=6918c4b6 or http://www.google.co.jp/search?q=00534ac2
TwitterException{exceptionCode=[6918c4b6-00534ac2 6918c4b6-00534a98 6918c4b6-00534a98 6918c4b6-00534a98], statusCode=-1, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=3.0.5}
at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:177)
at twitter4j.internal.http.HttpClientWrapper.request(HttpClientWrapper.java:61)
at twitter4j.internal.http.HttpClientWrapper.post(HttpClientWrapper.java:98)
at twitter4j.auth.OAuthAuthorization.getOAuthAccessToken(OAuthAuthorization.java:180)
... 4 more
i don't know this error, what should i do? help plz.
The exception says it's unable to find a valid certification path. When doing a SSL request, the HTTP client needs to have access to a list of certificates that will be used to check if the server certificate is valid.
To fix this, you will need to find what path should be used for the HTTP client you are using AND if this path has all the certificates to be able to check for validity when trying to connect to api.twitter.com.
Usually you can find information about that path in the documentation of your language main libraries.
I missed this update, and only just today noticed that one of my applications has been failing to authenticate users and post tweets on their behalf for the past few days. I changed all the api endpoints in my twitter library to use the https protocol, and now it's working properly again.
got a fix from a developer...now seeing this: Exception: Server error: error setting certificate verify locations: CAfile: twitter.crt CApath: /etc/ssl/certs
@beercodebeer same issue here, I missed that post too. A few of our older servers running CF9 that haven't been updated stopped working like @chcibelli reported. Looks like I'll have to make time to patch those bad boys. Thanks y'all.
Replies
Hello, how can I make sure I will not have issues when the certificate change is done? I use https connection from a Windows desktop app (.NET framework). I guess I shouldn't have problem, but is there a development environment to test?
Thank you
Hi Karl,
We are planning to open some test windows in the next weeks, I'll publish in this thread soon.
As an alternative, userstream.twitter.com certificate was updated in beginning of November and it's using the same certificate that will be deployed in REST API. You can send a HEAD request to User streaming endpoint to check if your are already trusting the right certificates. If this is not the ideal test environment for you, please, subscribe to this thread to know when we are going to open the test window.
A test window will be available on Tuesday, December 3rd. It will available around 11:30am PST. Subscribe to this discussion to receive test details.
Confirming that tomorrow (Dec 3rd), from 11:30am to 1pm PST, the servers at api.twitter.com will have the new certificate deployed. After this period a rollback will be done. This is a great opportunity to check if your application is trusting the new certificates that will be permanently deployed in Dec 10th, 2013 (see REST API SSL certificate updates)
If your application gets impacted by this test, the action required is to include the new root certificates in your servers and make sure all HTTP clients are aware of them.
Please, also make sure you have certificate verification always enabled when using Twitter APIs.
can you confirm if the rollback was indeed 1pm PST. Still having some issues almost 30 mins after 1pm PST.
The rollback started at 1pm PST and it can take up to one hour to affect all servers. So it's expected to still have issues after this period if your app isn't trusting the new certificates.
Has the certificate been installed? Some of my requests work others do not. Also when going to api.twitter.com I sometimes get the old version and sometimes the new one. I noticed to that the newer certificate only started showing for me an hour later 11:30am PST.
We have seen a new problem on two different sites that is preventing twitter app login using the API since around 20:30 UTC on the 3rd (about 2.5 hrs ago).
We have tested other aspects of the API, and they seem to work just fine (tweet, retweet, favouriting etc).
It is just the last step to get the access token after the callback to 'finalize' that's is failing, we get a 403. This has been tested also on multiple hosts, as well as with the different apps with the same result. Also both hosts have the correct time set.
FWIW, using curl it seems we are still getting the new certificate coming through :
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 - G2Thanks for the details John, this looks like an unrelated but similarly timed issue. While definitely you should be using SSL on these methods, the enforcement shouldn't be occurring right now. I'll see what's up.
This seems to have broken twitter4j 3.0.3 (and older, I'm assuming). An upgrade to 3.0.5 fixed my application.
OK, yes, seems some old code that was working up to today is now not working.
Found a single old reference to a http:// endpoint in our code that had been working just fine up until today, changed it to https:// and all is working again.
So if you're seeing issues, look for any remaining non SSL references in your code as these appear to have been only finally fully deprecated today.
I ran into the same issue as well. Our code was connecting with Twitter over HTTP instead of HTTPS, and after changing it to HTTPS all is well again.
I am VERY curious as to why connections over HTTP isn't working with the new certificate... Any ideas?
The issues with oauth/access_token and using HTTP should now be resolved. It was unrelated and only coincidental to the SSL certificate changes.
A got never see @stevendastine
Update: the new certificates were deployed successfully.
hello, I downloaded the root package for VeriSign Certificates (roots.zip file)
and then what should I do?
I'm using centos5 and php
My problem is
1. I don't know how to update VeriSign Certificates on my server. I'm using CentOS.5.xx
I found this /etc/pki/tls/certs/ca-bundle.crt
2. I couldn't find -3 option in curl commands..
curl -3 -capath --ssl https://api.twitter.com
and -capath means /etc/pki/tls/certs/ca-bundle.crt ??
3. I looked up EpiCurl.php that I'm using but I couldn't find the place where I can put these
1.curl_setopt($connection, CURLOPT_SSL_VERIFYPEER, True);
2.curl_setopt($connection, CURLOPT_SSL_VERIFYHOST, 2);
3.curl_setopt($connection, CURLOPT_CAINFO, "path:/ca-bundle.crt");
Thank you inadvance.
There's no need to change the library you're using, in PHP there's a global configuration you can change (for PHP 5.3.7 or superior):
1) download http://curl.haxx.se/ca/cacert.pem and save it somewhere. (this pem file already has Verisign root needed for api.twitter.com)
2) update php.ini -- add curl.cainfo = "PATH_TO/cacert.pem"
Otherwise you will need to do the following for every cURL resource:
curl_setopt ($ch, CURLOPT_CAINFO, "PATH_TO/cacert.pem");Reference: http://stackoverflow.com/a/16495053/2933153
I followed the 1, 2 and restarted Apache
and added CURLOPT_CAINFO like this but it doesn't work yet...
protected function curlInit($url)
{
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, $this->headers);
curl_setopt($ch, CURLOPT_TIMEOUT, $this->requestTimeout);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $this->connectionTimeout);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
if(isset($_SERVER ['SERVER_ADDR']) && !empty($_SERVER['SERVER_ADDR']) && $_SERVER['SERVER_ADDR'] != '127.0.0.1')
curl_setopt($ch, CURLOPT_INTERFACE, $_SERVER ['SERVER_ADDR']);
if($this->useSSL === true)
{
// curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
// curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_CAINFO, "/home/cacert.pem");
}
return $ch;
}
solved it
//if($this->useSSL === true)
// {
// curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
// curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_CAINFO, "/home/cacert.pem");
// }
return $ch;
Thank you for helping me a lot! :)
Hi, im using PHP and still doesnt work. Im getting "401" when call request_token
Thanks,
Has anyone successfully done this with ColdFusion? The cfhttp tag in ColdFusion 9 does not work with the new certificate. I've imported the .cer and .pem files for the "VeriSign Class 3 Public Primary CA - G3" version, and the ColdFusion keystore utility indicated the imports were successful. But I'm still not able to connect to the API (it worked perfectly before the new certificate). Thanks!
@ckryanco same problem here with CF, I'm using monkeh tweet lib, everything works great before new certificade
Same problems with CF8 and Monkeh Tweet. Until I can work out the new SSL certificate issues, I just changed the api endpoints in base.cfc to use http instead of https. Not ideal, but it'll work for now, and it'll save me yet another frustrating day of attempting to debug this issue.
@beercodebeer Thanks, I will try your fix, not best practice but at least it will work until solution cames up
Unfortunately, CF 9 Enterprise w/Monkeh isn't working since Twitter changed their SSL certs. If anyone figures out how to get CF9 to see these new certs, please post. I haven't been trying very long but so far I've had zero luck.
Since I couldn't get the cacerts changes to work in ColdFusion 9 Ent and am out of time, I just changed base.cfc in MonkehTweet to use http instead of https and my application is at least useable for the time being. Thanks for the tip @beercodebeer.
If anyone here can get these new certs to work with CFHTTP, please post your solution. Thanks!
-JD
I was able to resolve the MonkehTweet Twitter SSL certificate issue by upgrading ColdFusion 9.01 Standard to use JDK 1.7 which includes the required certificates. In order to do this, I first installed the 9.02 Cumulative Hotfix 1 on 9.01. Follow the instructions at:
http://helpx.adobe.com/coldfusion/kb/cumulative-hotfix-1-coldfusion-902.html
I'm not sure if the hotfix is required to use JDK 1.7 on 9.01 but it worked for me. I could not upgrade to 9.02 as is does not include Verity support which I needed. Once the JDK upgrade was complete, I was good to go without any further fussing with certificates. This was successful on three different servers.
I am a ColdFusion developer. I have downloaded the new certificates from ' https://www.symantec.com/page.jsp?id=roots '.
Could you please let me know where i put these certificates???
Thanks in advance
Have successfully got ColdFusion 8 to connect to the twitter API with the new certificates. Note that is isn't just once certificate you need to add to trustStore, but TWO:
Generation 3 (G3) PCAs - RSA2048/SHA1 - VeriSign Class 3 Public Primary Certification Authority - G3
Generation 5 (G5) PCA - RSA2048/SHA1 - VeriSign Class 3 Public Primary Certification Authority - G5
Both need to be added for connections to work. You can download them here: https://www.symantec.com/page.jsp?id=roots
Thanks @seajays - I haven't installed G5... I'll give that a shot in CF 9 Enterprise and report back. Appreciate it... -JD
A few of the servers that I manage are running ColdFusion 9 Enterprise multi server. When Twitter updated their SSL certificates on December 10th, 2013 (I believe that's the date) my applications that use monkehTweet stopped working and couldn't connect to Twitter using CFHTTP.
After adding the following certs to my cacerts file using the keytool utility in C:\JRun4\jre\bin, I finally have it working in CF 9 Enterprise!
The certs are:
1. VeriSign Class 2 Public Primary CA - G2 (http://www.verisign.com/repository/roots/root-certificates/PCA-2G2.pem)
2. VeriSign Class 3 Public Primary CA - G3 (http://www.verisign.com/repository/roots/root-certificates/PCA-2G3.pem)
3. VeriSign Class 3 Primary CA - G5 (http://www.verisign.com/repository/roots/root-certificates/PCA-3G5.pem) ***(thanks for the tip @seajays! this was the one that I was missing)
Download each of the certs above and save them to C:\JRun4\jre\lib\security (or wherever you'd like, just change the paths in the keytool commands below)
Open a Windows CMD prompt and change directories to C:\JRun4\jre\bin
Run the following keytool commands to add the required certs to you cacerts file
(these commands assume you are using the default password: changeit)
Then restart ColdFusion and you should be back in business!
-JD
Is the second link right there - it looks like it's linking to Class 2 G3, instead of Class 3 G3?
Yep, I couldn't edit my post after comments were added. Typo on my part...
If we run below command"
keytool -import -v -alias PCA-3G3 -file C:\JRun4\jre\lib\security\PCA-3G3.pem -keystore C:\JRun4\jre\lib\security\cacerts -storepass changeit
It throws
keytool error: java.lang.Exception: Input not an X.509 certificate
Thank you and @seajays for this, the problem we were having is that we didn't have Class 3 G5 in our cacerts file. Added them and restarted, now it's working like a charm.
So after trying nearly everything I could think of, I finally got it working. Here are the steps I took to resolve the issue on ColdFusion 8 Standard with monkehtweet.
First, I went to https://api.twitter.com in Firefox. Once there, I went to Tools -> Page Info. On the Security tab, I clicked View Certificate, then clicked the Details tab, then Export and saved the file as a .cer file (api.twitter.com.cer). I then copied this file to c:\cert on my CF8 dev box.
I then remoted in to my dev box and ran a command prompt. I had to right-click on the shortcut and select 'Run as Administrator' in order for this to work properly.
I then changed to the directory where keytool resides - c:\coldfusion8\runtime\jre\bin\ - and ran the following command:
keytool -import -v -alias twitter-cert -file c:\cert\api.twitter.com.cer -keystore c:\coldfusion8\runtime\jre\lib\security\cacerts -storepass changeitI restarted CF8 Application Server and ran my test page that makes an https call to the Twitter api, and finally received a successful result (rather than the dreaded "Connection Failure" message).
For posterity, here are some things that did NOT work for me.
Following guidance from here (https://dev.twitter.com/blog/rest-api-ssl-certificate-updates), where Twitter mentions the impending SSL update, I went to the Symantec page and downloaded/installed the Class 3 Gen 3 certificates. However, when importing them, I was told they already existed in the keystore. I went ahead and overwrote the existing keys, but that was no help. Eventually, I resorted to downloading and resinstalling ALL of their public certificates. Most were already present, some were not, and one gave me an error. But even this had no effect. This was on a separate dev box than the one I'm referring to above, by the way, so I know that it was not a combination of things that led to a successful resolution, but rather just the cert from api.twitter.com.
Thanks @beercodebeer with your tips I am able to solve twitter certificate issue.
Thanks @beercodebeer, worked perfectly, thanks for taking the time to figure this out and share. Appreciated.
@beercodebeer -- Do you know if something has just changed to make this not work? This approach worked perfectly until yesterday, when I started getting the dreaded connection failure again...
Hi @ckryanco. I did have to repeat this process recently. It looks like Twitter recently updated their SSLs again (probably related to the Heartbleed bug), but following the steps above resolved the recurring Connection Failure error for me.
I expected the new Java versions to already have these new Verisign CA certs and for the most part they do. I am working on this issue for a client and I have been testing with a dev setup that has both CF8.0.1 and CF10 installed. Both CF versions are using the same Java install and cacerts file. CF10 works and CF8 does not. Even another setup with CF9 is working. The JVM version in play here is 1.6.0_45. For those with an older JVM installed an upgrade of the JVM may be all you need if running CF9. And CF9 will run on JVM 1.7.0_nn once you fully patch CF9. I'm wondering if those that have this working on CF8 have forgotten they had switched to http instead of https before hand?
Hi all, I developed an IoT device which is build around a small micro controller and the .NET micro framework.. The device was able to send out tweets using API 1.0 Software in the device used direct socket programming to communicate with the API. The new API requires SSL and requires a lot of extra software in the device and will adds a performance penalty. Is a secure connection really needed also from small embedded devices to use the current API?
Thanks in advance!
Rob
i upgraded to twitter4j 3.0.5, already.
but i have still problem like this.(using xauth)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Relevant discussions can be found on the Internet at:
http://www.google.co.jp/search?q=6918c4b6 or
http://www.google.co.jp/search?q=00534ac2
TwitterException{exceptionCode=[6918c4b6-00534ac2 6918c4b6-00534a98 6918c4b6-00534a98 6918c4b6-00534a98], statusCode=-1, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=3.0.5}
at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:177)
at twitter4j.internal.http.HttpClientWrapper.request(HttpClientWrapper.java:61)
at twitter4j.internal.http.HttpClientWrapper.post(HttpClientWrapper.java:98)
at twitter4j.auth.OAuthAuthorization.getOAuthAccessToken(OAuthAuthorization.java:180)
... 4 more
i don't know this error, what should i do? help plz.
The exception says it's unable to find a valid certification path. When doing a SSL request, the HTTP client needs to have access to a list of certificates that will be used to check if the server certificate is valid.
To fix this, you will need to find what path should be used for the HTTP client you are using AND if this path has all the certificates to be able to check for validity when trying to connect to api.twitter.com.
Usually you can find information about that path in the documentation of your language main libraries.
We are seeing the same issue but with twitter4j 3.0.6-SNAPSHOT
This is a very basic test servlet that only makes the API call. It is running on JBoss 5 (java 1.6.0_16) on RHEL.
2013-12-19 00:03:19,468 ERROR [STDERR] (ajp-10.29.236.252-8009-5) sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Relevant discussions can be found on the Internet at:
http://www.google.co.jp/search?q=00df323f or
http://www.google.co.jp/search?q=44677343
TwitterException{exceptionCode=[00df323f-44677343 c60d4d36-4886f0e3 c60d4d36-4886f0e3 c60d4d36-4886f0e3], statusCode=-1, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=3.0.6-SNAPSHOT(build: 6b148528110cab823a73f4ae60f90cae89fd2fb5)}
...
2013-12-19 00:03:19,470 ERROR [STDERR] (ajp-10.29.236.252-8009-5) Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
2013-12-19 00:03:19,470 ERROR [STDERR] (ajp-10.29.236.252-8009-5) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
Verified the keystore has the VeriSign Cert:
Alias name: verisignclass3g3ca
Creation date: Mar 25, 2004
Entry type: trustedCertEntry
Owner: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Serial number: 9b7e0649a33e62b9d5ee90487129ef57
Valid from: Thu Sep 30 17:00:00 PDT 1999 until: Wed Jul 16 16:59:59 PDT 2036
Certificate fingerprints:
MD5: CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09
SHA1: 13:2D:0D:45:53:4B:69:97:CD:B2:D5:C3:39:E2:55:76:60:9B:5C:C6
Signature algorithm name: SHA1withRSA
Version: 1
Thanks for any suggestions!
Im getting 401 when trying to request_token, could be related to this update? It worked perfect and start failing on jan 14th
Thanks,
Hi Christian.
I don't know if this is related to your issue, but the timing looks right. Twitter is now enforcing that all api calls be made via https.
https://dev.twitter.com/discussions/24239
I missed this update, and only just today noticed that one of my applications has been failing to authenticate users and post tweets on their behalf for the past few days. I changed all the api endpoints in my twitter library to use the https protocol, and now it's working properly again.
Hope this helps.
This code is usually related to wrong assignment of app tokens in your configuration. Please do the recheck and try again. Thanks
got a fix from a developer...now seeing this: Exception: Server error: error setting certificate verify locations: CAfile: twitter.crt CApath: /etc/ssl/certs
Thoughts?
@beercodebeer same issue here, I missed that post too. A few of our older servers running CF9 that haven't been updated stopped working like @chcibelli reported. Looks like I'll have to make time to patch those bad boys. Thanks y'all.