No conozco los detalles de iOS, pero el principio debería ser el mismo.
En teoría, si logra que sus clientes instalen y confíen en su certificado de CA, esos clientes confiarán en cualquier certificado que emita. Un ataque de intermediario no debería poder falsificar estos certificados, a menos que se apoderen de su clave privada de CA. Por lo tanto, en este sentido, su solución debe estar protegida contra ataques de intermediarios.
Las desventajas de usar dicha solución, en lugar de obtener un certificado emitido por una de las CA raíz de confianza es :
-
Implementación : con su enfoque, tendría que instalar manualmente su propia CA como de confianza en todos sus dispositivos. Los usuarios con otros dispositivos (sin su certificado de CA) no tendrán esto instalado y tampoco se conectarán, o tendrán que aceptar manualmente un certificado desconocido (y por lo tanto no confiable). En cuyo caso, el ataque del hombre en el medio es una posibilidad real.
-
Revocación : Qué sucede si su CA o la clave privada del servidor se exponen de alguna manera. ¿Cómo puede decirle a todos sus dispositivos que no confíen más y, en cambio, que confíe en un nuevo certificado? Las CA confiables de terceros suelen proporcionar servicio para realizar comprobaciones de revocación para evitar esto. Es posible que pueda hacer algo similar por su cuenta, pero aumenta la complejidad de forma espectacular
-
CA Security : si bien esto no está garantizado, es probable que las autoridades de certificados de confianza tengan una seguridad más estricta. Este es su negocio central, después de todo.
-
Precio / problema : imagino que el costo de emitir un certificado a su servidor con una CA de terceros debe ser significativamente más bajo que ejecutar todo esto por sí mismo. Esto, por supuesto, depende de sus circunstancias, por ejemplo. cuántos dispositivos, qué seguridad / recursos ya tienes, etc.