I have written lots of Java code accessing HTTPS sites with 2048 or 3072-bit RSA. This is perfectly supported. You do not even need the Unlimited Strength Jurisdiction Policy Files to use such RSA key sizes (other algorithms are restricted).
I can't comment on Android Browser on Google TV, but I very highly doubt it fails to support 2048-bit RSA keys. If that was the case, half the HTTPS websites would be unbrowsable(!) [1]
[1] Per the EFF SSL observatory dataset, roughly 1 in 2 websites uses key lengths strictly higher than 1024 bits.
We had downtime for this, so I am 100% sure. We isolated it to the key, and reverting the cert/key back to 1024 fixed it. It was just an option on GoDaddy one of the engineers picked to generate a 2048 cert. They only offer 1024 and 2048. One key worked, the other didn't.
It must have been something else that broke it, not the key size. Android Browser definitely supports 2048-bit RSA certs. Maybe a root cert was absent from the browser (GoDaddy would be using a different root for 2048-bit certs?). Or maybe intermediate certs were missing in the certificate path. It sounds like your engineer did not spend much time trying to figure out what aspect of SSL/X.509 was actually causing the problem.
There were no problems with accessing the site with Chrome or other modern browsers. What you described would have been a problem with all browsers, and anyway GoDaddy supplies all the files you need in a single zip file, including the intermediate certs. We did simply revert the SSL key, once we isolated that to be the problem. There is no pressing business need for a 2048-bit key.
That is incorrect. Mobile browsers, the JVM, etc, notoriously lag behind desktop browsers when it comes to updating the list of root certs (and intermediate certs too, but that seems irrelevant in your case). The consequence is that a site can be accessed from the desktop, but not from a mobile.
It was a recurrent problem at a previous job with a Java app accessing HTTPS sites. We could not always update the JVM (which comes with the most recent list of roots in "cacerts"), so we had to develop a solution to push the latest cacerts truststore to our application. Problem fixed.
Do you know if Android Browser users reported at least an ability to click through an SSL warning to get to the site?
Yes, now I remember, I think you are correct. They were able to click through the SSL warning but because we use socket.io they had additional problems. Some of our customers do not employ full time engineers and whatever script they were using with our API were using libraries that couldn't handle the SSL cert change and they could not easily update them. We couldn't ask our customers, mostly sales and customer service oriented directors, to handle a complicated certificate change either.
