En el caso de la autenticación de certificado de cliente, ¿quién debería emitir el certificado de cliente?
¿El proveedor de servicios que expone la API o el consumidor cliente que consume la API?
En mi experiencia, he visto ambos enfoques pero me gustaría saber lo que dicen los textos sagrados.
El consumidor de API debe generar un CSR, generalmente, de modo que haya confianza en que el consumidor es la única parte con la clave privada correspondiente para el certificado. La emisión del certificado puede ser realizada por el proveedor del servicio (firmado por el servicio), el cliente (autofirmado) o una CA de confianza de terceros (firmada por la CA).
Si el proveedor de servicios crea la CSR del cliente, existe un problema de integridad, ya que potencialmente podrían emitir el mismo certificado para varios usuarios finales. Esto no siempre es un problema: si el certificado se usa para asegurar un canal y se toman más pasos para la autenticación, por ejemplo, o si se usa para una conexión inicial donde se puede transferir una clave pública específica del cliente, pero no es ideal.
De manera similar, si el servicio requiere que el certificado del cliente esté firmado por un tercero de confianza, eso no funcionará si el servicio lo genera; los pasos de verificación del tercero se aplicarían al servicio, en lugar de a la real Usuario final, anulando los beneficios. Sin embargo, no es raro que los proveedores de servicios firmen certificados de clientes, lo que les permite tener una lista muy pequeña de certificados de raíz de confianza (los propios) y no requiere que el cliente exponga la clave privada a nadie. En su lugar, el cliente envía una CSR al servicio, obtiene un certificado en respuesta y puede usarlo junto con la clave, que nunca ha dejado su control.
¿Quién debería emitir el certificado de cliente?
Una autoridad aprobada en la que confía el proveedor de servicios API. No es necesario que el proveedor de servicios API en sí mismo (sin embargo, es común), esta tarea puede delegarse a otra entidad que seguirá los requisitos establecidos por el proveedor de API. Cuando esté delegado, el proveedor de API debe tener la seguridad de que solo los clientes legítimos y debidamente autenticados reciben certificados de cliente.
Ciertamente, no el cliente es responsable de crear certificados de cliente.
Según el caso particular, puede haber varios escenarios comunes:
Este es el enfoque más simple. El cliente genera CSR y lo envía a la CA del proveedor de servicios. Cuando la solicitud se autentica y valida correctamente, el cliente recibe un certificado firmado que luego se utiliza para acceder a la API.
Pros: el proveedor de servicios rastrea a todos los clientes individuales y sus certificados.
Contras: el proveedor de servicios debe mantener toda la infraestructura para trabajar con la validación de las solicitudes de los clientes y mantenerlas (renovar, volver a emitir, revocar, etc.). Puede tener una sobrecarga notable (para ambas partes) cuando las entidades clientes no están estrictamente definidas. Es decir, cuando tiene solo 5 clientes, este enfoque es ciertamente bueno. Cuando tiene miles, esto puede ser un problema, porque el proveedor de servicios tendrá que seguir el SLA.
Esta opción es necesaria para tener un PKI privado operable en ambas organizaciones, proveedor de servicios y organización cliente. La organización del cliente puede tener un gran número de entidades cliente que pueden acceder al proveedor de servicios.
Pros: reduce los costos de administración de certificados en el extremo del proveedor de servicios. Especialmente cuando el número exacto y el nombre de las entidades cliente no se conocen de antemano (por ejemplo, el acceso se otorga por departamento). Permite una mejor gestión del ciclo de vida de los certificados dentro de la organización del cliente.
Contras: requiere una confianza cualificada entre la organización cliente y la organización proveedora de servicios. Esto abre un agujero cuando la organización del cliente puede perder los certificados de los clientes y no se considera confiable. Esta pregunta generalmente se resuelve mediante el uso de auditorías PKI por parte de una compañía de auditoría de terceros. Habrá una política escrita que describa todas las relaciones técnicas y legales entre las organizaciones. Pero este enfoque también es costoso (auditorías, políticas de redacción, etc.).
En algunos casos, este escenario se amplía a más de 2 organizaciones y, para limitar un número de certificados cruzados, se construye una CA de Bridge para organizar una confianza entre organizaciones.
Tengo que estar en desacuerdo con la respuesta de Crypt32.
(Supongo que por "problema" que te refieres a "firmar")
Debería ser una entidad de confianza tanto para el proveedor del servicio como para el cliente, y debería ser otra otra que no sea el proveedor del servicio y el cliente.
Dado que el proveedor de servicios presumiblemente confía en el cliente una vez que se autentican, no es irrazonable confiar en que la organización del cliente firme el certificado del cliente, sin embargo, en términos prácticos, hace que la vida del proveedor de servicios sea mucho más difícil de mantener. Certificados de CA.
El propósito del certificado es identificar públicamente una entidad, por lo tanto, si bien es probable que el cliente confíe en que el proveedor firmará un certificado para ellos, esto generalmente solo proporcionará un certificado que puede ser validado por el proveedor del servicio. . Si el certificado se usó en interacciones con otros proveedores, le otorga al proveedor original el control sobre las interacciones de los clientes con otros.
El uso de un tercero como CA proporciona protección tanto al cliente como al proveedor y separa los problemas técnicos y organizativos (contractuales) relacionados con la gestión de certificados de la relación existente alrededor del servicio.
Lea otras preguntas en las etiquetas authentication tls certificates