CA raíz con campos de uso de clave extendida

2

Recientemente comencé a usar el Administrador de certificados de AWS para obtener certificados TLS gratuitos para mi equilibrador de carga. Cuando estaba inspeccionando la cadena de certificados, me di cuenta de que la CA raíz,

  • cliente SSL
  • servidor SSL
  • servidor SSL de Netscape
  • firma S / MIME
  • cifrado S / MIME
  • firma de CRL
  • cualquier propósito
  • ayudante de OCSP
  • firma de marca de tiempo

Luego abrí la tienda Trusted Root Certification Authorities en una computadora portátil con Windows que tengo y comencé a buscar en varias CA raíz. Resulta que muchos de ellos tienen valores de EKU iguales o muy similares. Entiendo por qué están presentes CRL y OCSP (aunque me imagino que la raíz se mantendría fuera de línea, lo que haría que OCSP sea un poco más difícil), pero ¿por qué los otros? ¿Esto significa que la CA, además de emitir certificados, también puede firmar código, realizar funciones S / MIME, etc.? ¿O la presencia de estos valores significa que los certificados que descienden de esta CA raíz solo pueden usarse para, como máximo, esos valores EKU?

Revisé brevemente la sección de Uso de clave extendida de RFC 5280 y lo único que vi sobre el tema fue este:

  

En general, esta extensión aparecerá solo en los certificados de entidad final.

Para resumir mis preguntas:

  1. ¿La colocación de estos valores EKU en el certificado CA raíz indica que los certificados de entidad final que descienden de esa raíz pueden tener, como máximo, esos valores EKU?
  2. Si no es 1, ¿por qué estos valores están presentes en varias CA raíz? ¿Es así que estas CA también pueden usarse para esos propósitos? Si es así, ¿por qué se querría hacer eso en lugar de emitir un certificado de entidad final con esos EKU?
pregunta Hmmmmm 23.09.2018 - 02:12
fuente

2 respuestas

2

La razón por la que ve que ExtendedKeyUsage list se debe simplemente a la aplicación utilizada por el sitio web vinculado en su pregunta para volcar la representación textual del certificado.

Si vuelve a mirar la página, verá una representación codificada en Base-64 del certificado. Copie y pegue en un archivo y guárdelo. Descargue la representación textual del certificado con OpenSSL y simplemente verá lo siguiente.

Nota: si está ejecutando Windows, guárdelo con una extensión .cer o .crt y haga doble clic en él. Windows mostrará el certificado en una GUI, mostrando información similar.

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier: 
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

Esto es lo que debería esperarse: no hay KeyUsage o ExtendedKeyUsage

Un certificado de CA raíz no debería contener ninguna extensión (aparte de las opciones SubjectKeyUsage y AuthorityKeyUsage usadas para ayudar en la construcción de la cadena), ya que limita el uso del certificado durante toda su vida útil. Tales limitaciones deben agregarse en el nivel de la CA subordinada.

Como indicó en su pregunta, el ExtendedKeyUsage es para el certificado en particular, no para la cadena (a diferencia de la política y las restricciones de nombre).

    
respondido por el garethTheRed 23.09.2018 - 10:21
fuente
1
  

¿La colocación de estos valores EKU en el certificado CA raíz indica que los certificados de entidad final que descienden de esa raíz pueden tener, como máximo, esos valores EKU?

esto es correcto. El EKU válido para un certificado en particular es (aproximadamente) la intersección de las restricciones de extensión de EKU en toda la cadena de certificados. Entonces, si un certificado CA tiene una extensión EKU que contiene OID1 y OID2, no puede emitir certificados que sean válidos para cualquier otro OID EKU.

Sin embargo, esto no es una regla estricta, depende de una aplicación cliente que realice la validación de certificados. Por ejemplo, para validar el certificado de firma de OCSP, es suficiente tener OCSP Signing (1.3.6.1.5.5.7.3.9) solo en el certificado de hoja (firma). No se requiere que toda la cadena sea válida para OCSP Signing usage .

Si el certificado emitido contiene otro OID EKU y la aplicación cliente pregunta si el certificado es válido para un uso específico, el motor de encadenamiento de certificados no considerará el certificado válido para ese OID.

Actualización 26.09.2018:

la declaración anterior no es parte de RFC. De hecho, RFC no restringe CA en la emisión de EKU.

Se trata de la implementación de un proveedor importante. Los sistemas y los navegadores generalmente implementan el almacenamiento interno de certificados (Certificate Store, KeyChain, TrustStore, etc.) y los sistemas de almacenamiento de certificados implementan propiedades conectadas a la tienda, donde usted o su proveedor pueden asignar atributos adicionales al certificado sin modificar el certificado de firma. Así es como se manejan las restricciones EKU en su certificado de ejemplo. Si abres el certificado, no encontrarás ninguna extensión EKU en él:

Sinembargo,dealgunamaneraincluyerestricciones:

YaquíescómoseestablecenlasrestriccionesatravésdelAlmacéndecertificadosdeWindows:

Como dije, la validación de EKU a través de la cadena es específica de la aplicación. Si la aplicación solicita la validación de EKU a través de la cadena y no se permite EKU en todos los certificados de CA en la ruta, la validación fallará. Si la aplicación requiere un EKU específico solo en el certificado de hoja y se presenta un EKU específico, la validación tendrá éxito.

p.s. En Windows no necesita usar OpenSSL para volcar el certificado, en su lugar puede usar la herramienta certutil.exe incorporada:

certutil -dump path\certfile.cer
    
respondido por el Crypt32 23.09.2018 - 08:00
fuente

Lea otras preguntas en las etiquetas