Tal vez algunas de las siguientes afirmaciones no sean precisas, pero en general, funciona de manera muy similar.
Realmente depende de la implementación. Pero la idea es que la clave privada nunca abandona el dispositivo que la está utilizando. Si es así es un diseño equivocado. No conozco ningún MDM (software de administración de dispositivos móviles) ya que no trabajé con ninguno anteriormente, pero funcionará de manera muy similar a la que describo a continuación.
El dispositivo móvil (iPhone en su caso) generará una clave privada. También creará la CSR (solicitud de firma de certificado, ya que de otros datos incluye una parte pública de la clave generada), tenga en cuenta que el MDM también puede generar la CSR y luego entregarla al iPhone para que la firme. Luego, el iPhone lo firma (lo procesa y lo cifra) utilizando la clave privada generada y lo envía a través de MDM a CA (autoridad de certificación) para su validación y aprobación. MDM es responsable de la autenticación del dispositivo antes de que se genere la primera clave. Diría que necesita iniciar sesión usando el nombre de usuario / contraseña de AD por primera vez desde una red confiable sin ningún método de autenticación, como 802.1x.
Una vez que la CA garantizará la validez de la CSR (esto también puede ser un proceso completamente manual) crea el certificado y lo firma con su clave privada. Almacena el certificado generado en el almacén de certificados emitidos y lo pasa de nuevo al MDM. MDM lo almacenará en AD (o no) y lo enviará de vuelta al dispositivo iPhone. Una vez que el dispositivo recibe el certificado firmado, comprueba si tiene el CSR apropiado almacenado en el interior (debe hacerlo como lo generó / firmó), combina la información del certificado firmado y el CSR y almacena el certificado, incluidas las partes pública y privada de la clave internamente generalmente para asegurar el almacén de certificados). La clave privada puede protegerse adicionalmente mediante algún otro tipo de protección (es decir, PIN, contraseña, tarjeta inteligente, lo que sea), por lo que el usuario debe autorizar el uso de la clave en tal caso. En el iPhone, diría que está protegido y encriptado con la contraseña / pin / huella digital del usuario para que una vez que desbloquees el teléfono se pueda usar.
Para la autenticación, (no importa si es 802.1x EAP-TLS u otro TLS u otro método que use certificados para la autenticación; todo funciona de manera similar) usted usa este certificado firmado con CA y generalmente algo firmado (encriptado) por su Clave privada relacionada con el certificado. Por lo general, es un tipo de desafío enviado por el servidor y se usa para probar que posee la clave privada relacionada con el certificado que envió al servidor para ser usado para la autenticación y usted afirma que es suya.
El servidor luego verifica su certificado (si es válido: fecha / hora, si no se revoca, si se supone que debe usarse para realizar la acción que realmente está intentando realizar y si está firmado con una autoridad de certificación confiable) ) luego utiliza la parte pública de la clave almacenada en el certificado para descifrar el desafío para asegurarse de que usted es el propietario del certificado (se utilizó la clave privada correcta para firmar los datos) Si el descifrado es exitoso y el desafío coincide con el desafío enviado a usted para que lo firme significa que usted es el propietario del certificado y que posee la clave privada relacionada con ese certificado.
Entonces, ¿qué necesita saber el servidor para autenticarlo? Solo la CA raíz o el certificado de autoridad de CA inmediata utilizado para firmar su certificado, su certificado que incluye su parte pública de la clave y los datos encriptados (firmados) con su clave privada relacionada con el certificado. Eso es suficiente para autenticarte y autorizarte. Nunca necesita conocer su clave privada, por lo que no hay razón para almacenarla en AD o en CA o en cualquier otro lugar que no sea en su dispositivo.
Algunas palabras sobre AD y MS PKI (servicio de CA) - es lo mismo que se indicó anteriormente :):
AD nunca almacena su certificado, incluida la clave privada. ¿Por qué? Porque simplemente no lo sabe. Nunca lo hizo Si solicita un certificado en MS PKI (otros funcionan de la misma manera o de manera muy similar: EJBCA, OpenCA ...), por lo general, funciona de la manera en que genera la clave privada en su computadora, luego crea la solicitud de firma de certificado. Esto se puede hacer en cualquier lugar, en el caso de MS, generalmente se realiza en el servidor de CA. CSR contiene, por ejemplo, nombre distinguido (nombre o correo electrónico), su dirección, para qué fines solicita el certificado, es decir,. autenticación, firma de correo electrónico, lo que sea). Luego obtiene la CSR y le agrega información, es decir, parte pública de la clave, huellas digitales, lo que sea. Finalmente, firma la CSR (hash la CSR y la encripta usando su clave privada) y luego la envía al portal de servicio CA propio. CA genera un certificado, lo firma y se lo devuelve de forma predefinida. Es decir. colocándolo en la web o por correo electrónico o, probablemente, también podría integrarse con MDM.
En este caso, no estoy 100% seguro de que el proceso descrito funcione así en detalle, pero será muy cercano a él.