Políticas Granulares

¿Cómo puedo lograr esto?

Keychain Access refleja lo que es posible con macOS. Un certificado tiene una sola política de confianza asociada, y la política define lo que está permitido:

macOS utiliza varias políticas de confianza para determinar si se confía en un certificado. Puede elegir una política diferente para cada certificado, lo que proporciona un mayor control sobre cómo se evalúan los certificados.

Puede leer la documentación del desarrollador de políticas que sustenta los marcos de seguridad de macOS. Las políticas predeterminadas en macOS se definen como:

Políticas de Confianza de macOS

Política

Descripción

Usar los valores predeterminados del sistema o no especificar ningún valor

Usar la configuración predeterminada para el certificado.

Confianza Siempre

Confiar en el autor y permitir siempre el acceso al servidor o la aplicación.

Nunca Confiar

No confiar en el autor y no permitir el acceso al servidor o la aplicación.

Seguridad de Capa de Conexión Segura (SSL)

El nombre en un certificado de un servidor debe coincidir con su nombre de host DNS para establecer correctamente una conexión. La verificación del nombre de host no se realiza para certificados de cliente SSL. Si hay un campo de uso de clave extendido, debe contener un valor apropiado.

Correo Seguro (S/MIME)

El correo electrónico utiliza S/MIME para firmar y cifrar mensajes de forma segura. La dirección de correo electrónico del usuario debe estar incluida en el certificado, y deben estar incluidos los campos de uso de clave.

Protocolo de Autenticación Extensible (EAP)

Cuando se conecta a una red que requiere autenticación 802.1X, el nombre en el certificado del servidor debe coincidir con su nombre de host DNS. Los nombres de host para los certificados de cliente no se verifican. Si hay un campo de uso de clave extendido presente, debe contener un valor apropiado.

Seguridad de Protocolo IP (IPSec)

Cuando se utilizan certificados para asegurar comunicaciones IP (por ejemplo, al establecer una conexión VPN), el nombre en el certificado del servidor debe coincidir con su nombre de host DNS. Los nombres de host para los certificados de cliente no se verifican. Si hay un campo de uso de clave extendido presente, debe contener un valor apropiado.

Firma de Código

El certificado debe contener configuraciones de uso de clave que permitan explícitamente firmar código.

Sellado de Tiempo

Esta política determina si el certificado se puede utilizar para crear un sello de tiempo de confianza, que verifica que una firma digital ocurrió en un momento particular.

Política Básica X.509

Esta política determina la validez del certificado frente a requisitos básicos como haber sido emitido por una autoridad de certificación válida, pero sin preocuparse por el propósito o el uso de la clave permitido.

Para la situación que describe, sería necesario crear una política personalizada.

Una aplicación puede crear políticas personalizadas para evaluar certificados, pero no es evidente una API para instalar políticas personalizadas en todo el sistema. Tampoco se menciona ninguna política personalizada en la herramienta de línea de comandos security.

Esto podría ser posible dentro de un entorno gestionado pero, nuevamente, no hay documentación evidente al respecto.

Todo esto significa que un enfoque más granular no es trivialmente posible con el marco de seguridad ofrecido por macOS.

No es necesario utilizar software de terceros para utilizar los marcos de seguridad integrados y podrían ofrecer el enfoque granular que busca.

Certificados Mínimos

¿Existe alguna manera de confiar en una AC para firmar certificados S/MIME pero no para autenticar conexiones cliente-servidor (o viceversa)?

Los certificados deben emitirse con las capacidades mínimas necesarias para desempeñar su función. Emita certificados según sea necesario para cada subfunción.

El certificado de ejemplo es demasiado amplio:

Extensión=Uso de Clave ( 2.5.29.15 )

• Crítico=SÍ
• Uso=
  • Firma Digital
  • No Repudio
  • Cifrado de Clave
  • Cifrado de Datos
  • Acuerdo de Clave
  • Certificar Clave
  • Firmar LCR

Extensión=Restricciones Básicas ( 2.5.29.19 )

• Crítico=SÍ
• Autoridad de Certificación=SÍ
• Restricción de Longitud de Ruta=2

Extensión=Uso de Clave Extendido ( 2.5.29.37 )

• Crítico=SÍ
• Propósito #1=Autenticación del Servidor ( 1.3.6.1.5.5.7.3.1 )
• Propósito #2=Autenticación de Cliente ( 1.3.6.1.5.5.7.3.2 )
• Propósito #3=Firma de Código ( 1.3.6.1.5.5.7.3.3 )
• Propósito #4=Protección de Correo Electrónico ( 1.3.6.1.5.5.7.3.4 )
• Propósito #5=Sellado de Tiempo ( 1.3.6.1.5.5.7.3.8 )
• Propósito #6=Firma OCSP ( 1.3.6.1.5.5.7.3.9 )
• Propósito #7=( 1.3.6.1.5.5.7.3.17 )
• Propósito #8=Firma de Código Comercial ( 1.3.6.1.4.1.311.2.1.22 )
• Propósito #9=Firma de Lista de Confianza de Certificados ( 1.3.6.1.4.1.311.10.3.1 )
• Propósito #10=Sistemas de Archivos Encriptados ( 1.3.6.1.4.1.311.10.3.4 )

Autorización de Autoridad de Certificación

¿Existe alguna manera de confiar en una AC para firmar certificados solo pertenecientes a un cierto dominio o subdominio, o a una lista de dominios o subdominios?

Una Autoridad de Certificación (AC) puede firmar cualquier certificado. El software evaluativo es responsable de realizar controles adicionales.

Publique una entrada de Autorización de Autoridad de Certificación de DNS para los dominios:

La Autorización de Autoridad de Certificación de DNS (CAA) es un mecanismo de política de seguridad en Internet que permite a los titulares de nombres de dominio indicar a las autoridades de certificación si están autorizadas para emitir certificados digitales para un nombre de dominio en particular. Esto se hace mediante un registro de recursos del Sistema de Nombres de Dominio (DNS) que se llama "CAA".