As noted in our blog post, Twitter is updating its SSL certificates for api.twitter.com, we are currently in the process of migrating api.twitter.com's SSL certificate from a Verisign G2 Root CA certificate to a Verisign G3 Root CA certificate. You can more about this process in our guide: Connecting to Twitter API using SSL.
Last night (April 25th, 2012) a portion of this migration was attempted and due to an unfortunate series of events, caused a number of connecting clients to be unable to properly verify the certificate chain (see this issue for more information). We believe these particular issues to be resolved now.
However, some API clients may still need to make some alterations to accommodate the G3 Root CA certificate. If you're having trouble following the instructions in Connecting to Twitter API using SSL, we can assist you in this transition below.
Thanks!

Replies
Can we possibly get a test endpoint to test our clients against the new SSL certificate, sort of like a canary deployment?
Thanks!
I have been using in my application The Oauth 2.0, I don't know Anything about SSL and how this announced Change is gonna affect my App, I need some help please about What to do to avoid conflicts Or misfunctioning in my App, is there some sort of Guide? Any help Will be appreciated.
Thanks!
We don't support OAuth 2.0 on Twitter -- but it's unlikely you'll need to worry too much about these issues. Most SSL-capable software developed after 1999 will not have issues with these certificate changes. If you do have issues, the Connecting to Twitter API using SSL will help you.
Taylor, are you really sure that the changes required and the docs provided that explain these changes are appropriate for the average skill set of a Twitter API programmer? I think there is a pretty big mismatch here. If not making the changes described here will mean that apps that work with the API break, then be prepared for a lot of breakage. Some of us have many apps out there on clients' servers. Some of those apps are no longer under our control. Clients are really reluctant to pay for ongoing maintenance. That is just the sad reality. Do we need to go back to every client and every app and warn them that another Y2K level upheaval is about to take place?
What exactly will happen if these changes are not made? That is what everyone better prepare for.
One of the downloads was harmful for my computer. I was even wondering if the email I received was from twitter
also taylor this is suppose to expire in 7 years? are you jumping the gun?
The root certificate for Verisign expires 7 years from now. SSL Certificates expire every 1-3 years and must be renewed.
I'm PHP Developer.
I don't know well about your new SSL certificate.
I need more example and simple guideline to change this SSL certificate.
Could you write more simple step for me?
a link would be appreciated greatly!
I am currently developing a Twitter client and I see a lot of "SSL handshake failed" in my debugs. I suppose that these changes are the cause of this "SSL handshake failed", aren't they ? If yes, do I need to reset the OAuth tokens of my app ?
I'm getting errors on OAuth HTTPS endpoints for Windows Phone 7 apps. Works fine on client apps. Has anyone figured out how to fix this yet?
Hi Joe,
In some cases, the issues with WP7 apps isn't having to do with SSL but instead having to do with Gzip encoding. The HTTP library commonly used sets a HTTP header requesting Gzip encoded content, despite the actual client code not necessarily being ready to decode responses of that type. You may want to look at whether you're getting garbled responses as a result of the gzip issue.
I'm not even getting that far. The URL is:
https://api.twitter.com/oauth/request_token
which matches the specified url at:
https://dev.twitter.com/docs/api/1/post/oauth/request_token
and I'm doing a GET.
Wireshark is showing a TLS error of:
Source: 199.59.148.87
Destination: Local machine
Content Type: Alert (21)
Alert Message: Encrypted Alert
I'm receiving the the following response from Twitter via Fiddler2:
--- Begin Fiddler Response ---
HTTP/1.0 200 Connection Established
FiddlerGateway: Direct
StartTime: 20:42:46.682
Connection: close
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls
Cipher: Rc4 128bits
Hash Algorithm: Sha1 160bitsKey Exchange: RsaKeyX 2048bits
== Server Certificate ==========
[Subject]
CN=api.twitter.com, OU=Twitter Security, O="Twitter, Inc.", L=San Francisco, S=California, C=US
[Issuer]
CN=VeriSign Class 3 Secure Server CA - G2, OU=Terms of use at https://www.verisign.com/rpa (c)09, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[Serial Number]
72BF383A9E113C1B13908E1A9F602CAE
[Not Before]
5/1/2012 6:00:00 PM
[Not After]
5/3/2013 5:59:59 PM
[Thumbprint]
935CC1CF7E4EC1078AFA25A1A3E379F0956BF99B
--- End Fiddler Response ---
This only happens on Windows Phone 7 - other platforms are unaffected.
According to this, all root certs are installed on Windows Phone: http://msdn.microsoft.com/en-us/library/gg521150(v=VS.92).aspx
Other, non-OAuth https queries work fine. i.e. The following request on Windows Phone 7 works:
https://search.twitter.com/search.json?q=LINQ%20To%20Twitter
The following post indicates that the problem is more widespread than what I'm seeing:
http://forums.create.msdn.com/forums/t/103644.aspx
If there's any info I can provide or anything I can do to get past this, let me know.
Joe
Thanks for the details Joe.
To help narrow down so possibilities, is this happening specifically on the device with the same error message? (Is there any chance the tools you're looking to observe the problem/error are changing, obfuscating, adding additional variables to, or interpreting the problem in an impure way?)
On the same device, are you able to use Twitter for Windows Phone without issue, including the authentication sequence?
It's certainly possible that there's device or other issues, but whatever is happening is difficult to figure out.
I'm experiencing this on the Visual Studiio 2010 WP7 emulator and I've tried it with both the WP7 SDK 7.1 and WP7 SDK 7.1.1. That said, the emulator works on non-oauth https endpoints, i.e. search. BTW, all of my code, including OAuth, was working well until recently and I haven't changed any of my OAuth code.
The WP7 Twitter app runs fine on my phone. Are you guys using OAuth on your WP7 app? I sign in with username/password. If you aren't using OAuth, then maybe you aren't experiencing the same problem because you aren't hitting the request_token endpoint?
Finally got it. There might have been something happening with SSL early on, but that cleared up a while ago. Today, I was getting a 401, which is something I can work with and I followed through to discover a timing error where my emulator time wasn't set the same as the Twitter server. This is a typical reason for a 401. I'll follow up with a blog post on how I debugged the problem.
BTW, the tip on the gzip compression was helpful because that's another issue I ran into.
Thanks,
Joe
Is it possible to verify exactly which root certs are required to prevent outages? Having to verify 3 digicert roots and 11 Verisign roots is problematic when you have many servers.
api.twitter.com host 199.59.148.20 is using the certificate 09 99 B8 E4 4C 3B 76 6B B6 1F EE 7E 60 BB DE 2E which has been on the SVRSecureG3.crl revocation list since 19:59:49 GMT this evening.
I also see the revoked certificate 09 99 B8 E4 4C 3B 76 6B B6 1F EE 7E 60 BB DE 2E
@inbound_tech and @lxalon - can you share your methodologies for determining this? Thanks.
Steps to reproduce:
Import the VeriSign CRL (if you haven't already done so) - http://svrsecure-g3-crl.verisign.com/SVRSecureG3.crl - Not sure about Chrome or other browsers, but Firefox will ask you to import the CRL when you click that link, and offer automatic updating. Always wise to have a CRL around anyway.
Then go to https://199.59.148.20
> An error occurred during a connection to 199.59.148.20.
>
> Peer's Certificate has been revoked.
>
> (Error code: sec_error_revoked_certificate)
@episod - you can get a list of revoked cert serial numbers (and when they were revoked) using the following command line (if you've got openssl and curl installed).
curl http://svrsecure-g3-crl.verisign.com/SVRSecureG3.crl | openssl crl -inform DER -text | grep -A1 "Serial Number"
And the following command line will get you the serial number of the cert used on a given host:
openssl s_client -showcerts -connect 199.59.150.9:443 | openssl x509 -serial -noout
Hope this helps,
Chris
Im just new to twitter. if you can give me a brief explanation as to what are the advantages and disadvantages on this site please. Right now I have a feeling of being a victim of something of being used and abuse!
can anybody explain how this works not a joke i have no idea as i have just returned from world tour and all this is new to me
Indeed we need to know more about the applications of Twitter. Personally ı feel that informaiton defect..by moving icon to the site http://www.elsatercume.com every details should be taken into cons. Regards..
Tercume
@twitter. Deactivate my account please