SSL issue on iPhone

Question

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

Safari and IE can view https: // and report that the certificate is valid, without warning. If, however, I try to go to the same address from the iPhone, I get an invalid certificate error. I use geroku as a host for the website in question.

Has anyone seen this? I’m stumped why 2 different iphones couldn’t do this, but desktop browsers are just perfect ...

Answer 1

---

The problem here was that the iPhone does not support server name identification (SNI), which is required to perform heroku SNI SSL. (EDIT) It is now supported by iOS 3.2 onwards.

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

https://sni.velox.ch

I realized that I can set the following SSL options in the iphone client:

kCFStreamSSLPeerName = Null

... and this fixes the problem. But I still do not understand how this affects security - the documents are not very clear.

As I understand it, when setting up a custom domain on a cloud node, such as heroku, it points to a proxy server, and this name does not match the host name of the certificate. Browsers such as Safari and IE support SNI and know how to figure it out, but the phone does not.

As I said above, now this is not a problem if you do not support iOS 3.1.3 or less ...

Answer 2

You also need to refer to the intermediate certificate to return the entire certificate chain to the root certificate.

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

Answer 3

Just because these two certificate authorities are not in the iPhone's trusted certificate store, but they are for Windows, firefox, etc.

EDIT:

I assume the previous poster is correct, you are not binding intermediate certificates. You can sign up for rapidssl.com, but the rapidssl.com certificate has been signed by Equifax. Each certificate has a field “Issuer name” and a field “Name of subject”; think of it as a pair of names (X, Y). The name of your certificate object reflects the name of your site, and it was signed by rapidssl, so the pair is something like (rapidssl, www.whatever.com). The rapidssl certificate was signed by equifax to make a pair (equifax, rapidssl). And equifax cert can have (equifax, equifax). The root certificate must 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 how long it takes. This is rarely longer than 3. The rule for SSL is that you must send all certificates in the chain except the root certificate. Some customers may already have an intermediate certificate (s), but you should never count on it.

Answer 4

I know that this was answered, but just in case someone again encounters this problem, I thought I would share what I missed, since I only recently experienced the same headache, but had a slightly different architecture .

Our server setup was a bit different, because we had to decrypt the stunnel ssl traffic, passing it to haproxy, which would redirect it to apache, which would proxy it on our application servers. After some interaction with apache, I realized that intermediate certificates are not included in the stunnel configuration, so I concatenated the domain certificate (first), and then the intermediate certificates (to make one large long chain of certificates).

This fixed the problem for me.