SSL problem on iPhone

问题:

I've added an SSL certificate (from godaddy, but also tried rapidssl) to a website.

Safari, and IE can both browse to https:// and report that the certificate is valid, with no warnings. If, however, I try to browse to the same address from an iPhone I get an invalid certificate error. I'm using heroku as a host for the website in question.

Has anybody seen this? I'm stumped why 2 different iphones would fail to do this, but desktop browsers are just fine...

回答1:

---

The problem here turned out to be that the iPhone does not support Server Name Indication (SNI), which is required to make SNI SSL from heroku to work. (EDIT) It is now supported on iOS 3.2 onwards.

You can confirm SNI by going to the following URL from Safari on the phone:

https://sni.velox.ch

I figured out I can set the following SSL setting in the iphone client:

kCFStreamSSLPeerName = Null

... and this fixes the problem. But I haven't figured out yet how this affects security - the docs aren't very clear.

As far as I understand this, when you setup a custom domain on a cloud host such as heroku, it points to a proxy, and that name doesn't match your certificate host name. Browsers such as Safari and IE support SNI, and know how to figure this out - but the phone doesn't.

As I said above, this is less of an issue now, unless you are supporting iOS 3.1.3 or less...

回答2:

You also need to reference the intermediate certificate so that you have the entire certificate chain back to the root certificate.

See this blog post for a description of the same problem and how he solved it for Apache.

回答3:

Simply because those two certificate authorities are not in the trusted certificate store of the iPhone, but they are for Windows, firefox, etc.

EDIT:

I'm guessing the previous poster is correct, you are not bundling the intermediate certs. You certificate might have been signed by rapidssl.com, but rapidssl.com's certificate was signed by Equifax. Every certificate has an Issuer Name field and a Subject Name field; think of these as a pair of names (X,Y). Your certificate's subject name reflects your website name, and it was signed by rapidssl, so that pair is something like (rapidssl, www.whatever.com). The rapidssl cert was signed by equifax, so that would make the pair (equifax, rapidssl). And the equifax cert might have (equifax, equifax). The root cert should have the same issuer and subject name. As you can see, this forms a chain of the form (A,A) (A,B) (B,C) (C,D) .... for however long it goes. It is rarely longer than 3. The rule for SSL is that you should send every certificate in the chain except the root certificate. Some clients may already have the intermediate cert(s), but you should never count on that.

回答4:

I know this has been answered, but just in case anyone comes across this problem again I thought I'd share what I missed since I just recently went through the same headache but have a slightly different architecture.

Our server setup was a little different in that we had stunnel decrypting ssl traffic, passing it on to haproxy which would route it to apache which would proxy it to our application servers. After messing with apache for a while I realized that the stunnel config did not include the intermediate certificates so I concatenated the domain certificate (first) and then the intermediate certificates (to make one big long chain of certificates).

That fixed the problem for me.