Problema SSL en el iPhone

Question

He agregado un certificado SSL (desde godaddy, pero también he intentado con rapidssl) a un sitio web.

Safari e IE pueden buscar https: // e informar que el certificado es válido, sin advertencias. Sin embargo, si trato de buscar la misma dirección desde un iPhone, recibo un error de certificado no válido. Estoy usando heroku como host para el sitio web en cuestión.

¿Alguien ha visto esto? Estoy perplejo por qué 2 iPhones diferentes no podrían hacer esto, pero los navegadores de escritorio están bien ...

Answer 1

---

El problema en este caso resultó ser que el iPhone no soporta Indicación Nombre del servidor (SNI), que se requiere para hacer SNI SSL de heroku a trabajar. (EDITAR) Ahora es compatible con iOS 3.2 en adelante.

Puede confirmar SNI yendo a la siguiente dirección URL de Safari en el teléfono:

https://sni.velox.ch

me di cuenta de que puedo establecer la configuración de SSL siguiente en el cliente de iPhone:

kCFStreamSSLPeerName = Nulo

... y esto soluciona el problema. Pero todavía no he descubierto cómo esto afecta la seguridad, los documentos no son muy claros.

Por lo que yo entiendo, cuando configura un dominio personalizado en un host en la nube como heroku, apunta a un proxy, y ese nombre no coincide con el nombre de host de su certificado. Los navegadores como Safari e IE admiten SNI y saben cómo resolverlo, pero el teléfono no.

Como dije anteriormente, esto ya no es un problema, a menos que usted soporte iOS 3.1.3 o menos ...

Answer 2

Simplemente porque esas dos autoridades de certificación no están en el almacén de certificados de confianza del iPhone, pero son para Windows, Firefox, etc.

EDIT:

estoy adivinando el comentario anterior es correcta, no estás liando los certs intermedios. Su certificado podría haber sido firmado por rapidssl.com, pero el certificado de rapidssl.com fue firmado por Equifax. Cada certificado tiene un campo Nombre del emisor y un campo Nombre del sujeto; piense en estos como un par de nombres (X, Y). El nombre del sujeto de su certificado refleja el nombre de su sitio web, y fue firmado por rapidssl, por lo que ese par es algo así como (rapidssl, www.whatever.com). El cert de rapidssl fue firmado por equifax, por lo que haría el par (equifax, rapidssl). Y el certificado de equifax podría tener (equifax, equifax). El certificado raíz debe tener el mismo emisor y nombre de sujeto. Como puede ver, esto forma una cadena de la forma (A, A) (A, B) (B, C) (C, D) ... por el tiempo que dure. Raramente es más largo que 3. La regla para SSL es que debe enviar cada certificado en la cadena excepto el certificado raíz. Algunos clientes ya pueden tener certificados intermedios, pero nunca debes contar con eso.

Answer 3

También necesita hacer referencia al certificado intermedio para que tenga toda la cadena de certificados de nuevo en el certificado raíz.

Consulte this blog post para obtener una descripción del mismo problema y cómo lo resolvió para Apache.

Answer 4

Sé que esto ha sido respondido, pero por si acaso alguien se encuentra con este problema otra vez, pensé en compartir lo que me perdí ya que recientemente sufrí el mismo dolor de cabeza pero tengo una arquitectura ligeramente diferente.

Nuestra configuración de servidor era un poco diferente en que teníamos que descifrar el tráfico de ssl de stunnel, pasándolo a haproxy, que lo enrutaría a apache, que lo enviaría a nuestros servidores de aplicaciones. Después de jugar con apache por un tiempo, me di cuenta de que la configuración de stunnel no incluía los certificados intermedios, así que concatenaba el certificado de dominio (primero) y luego los certificados intermedios (para crear una gran cadena larga de certificados).

Eso me solucionó el problema.