Saltar al contenido

Extensión de uso de clave CA OpenSSL

Te doy la bienvenida a nuestro sitio web, en este sitio encontrarás la solucíon de lo que buscabas.

Solución:

  • Prediseñado openssl.cnf y un ejemplo de cómo usar
    • Información, con comandos necesarios a partir de la línea 430

Autoridades de certificación y CA intermedias

CA autofirmada

  • clavecRLSign, digitalSignature, keyCertSign

    • No debe contener ningún otro KU o EKU

  • Perfil V3:

      [ v3_ca ]
  basicConstraints        = critical, CA:TRUE
  subjectKeyIdentifier    = hash
  authorityKeyIdentifier  = keyid:always, issuer:always
  keyUsage                = critical, cRLSign, digitalSignature, keyCertSign
  subjectAltName          = @alt_ca

CA intermedia

  • clavecRLSign, digitalSignature, keyCertSign

    • No debe contener ninguna otra KU o EKU

  • Perfil V3:

      [ v3_ica ]
  basicConstraints        = critical, CA:TRUE, pathlen:1
  subjectKeyIdentifier    = hash
  authorityKeyIdentifier  = keyid:always, issuer:always
  keyUsage                = critical, cRLSign, digitalSignature, keyCertSign
  subjectAltName          = @alt_ica
    • Dónde pathlen: es igual al número de CA / ICA que puede firmar
    • No puede firmar otras CA / ICA si pathlen: está establecido en 0

Certificados sin CA

Servidor VPN

  • clavenonRepudiation, digitalSignature, keyEncipherment, keyAgreement

  • Perfil V3:

      [ v3_vpn_server ]
  basicConstraints        = critical, CA:FALSE
  subjectKeyIdentifier    = hash
  authorityKeyIdentifier  = keyid:always, issuer:always
  keyUsage                = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement 
  extendedKeyUsage        = critical, serverAuth
  subjectAltName          = @alt_vpn_server

Cliente VPN

  • clavenonRepudiation, digitalSignature, keyEncipherment

  • Perfil V3:

      [ v3_vpn_client ]
  basicConstraints        = critical, CA:FALSE
  subjectKeyIdentifier    = hash
  authorityKeyIdentifier  = keyid:always, issuer:always
  keyUsage                = critical, nonRepudiation, digitalSignature, keyEncipherment
  extendedKeyUsage        = critical, clientAuth
  subjectAltName          = @alt_vpn_client

keyUsage

CA SOLAMENTE

keyCertSign

  • Público sujeto key se utiliza para verificar firmas en certificados
  • Esta extensión solo debe usarse para certificados de CA

cRLSign

  • Público sujeto key es verificar firmas en la información de revocación, como una CRL
  • Esta extensión solo debe usarse para certificados CA

digitalSignature

  • El certificado se puede utilizar para aplicar una firma digital.
    • Las firmas digitales se utilizan a menudo para la autenticación de entidades y la autenticación de origen de datos con integridad

nonRepudiation

  • El certificado se puede utilizar para firmar datos como se indicó anteriormente, pero el certificado es público key se puede utilizar para proporcionar servicios de no repudio
    • Esto evita que la entidad firmante niegue falsamente alguna acción.

keyEncipherment

  • El certificado se puede utilizar para cifrar un simétrico key que luego se transfiere al objetivo
    • Destino descifra key, usándolo posteriormente para cifrar y descifrar datos entre las entidades

dataEncipherment

  • El certificado se puede utilizar para cifrar y descifrar los datos reales de la aplicación

keyAgreement

  • El certificado permite el uso de un key protocolo de acuerdo para establecer un simétrico key con un objetivo
  • Simétrico key luego se puede utilizar para cifrar y descifrar los datos enviados entre las entidades

encipherOnly

  • Público key se utiliza solo para cifrar datos mientras se realiza key convenio
    • Req. KU:keyAgreement

decipherOnly

  • Público key se usa solo para descifrar datos mientras se realiza key convenio
    • Req. KU:keyAgreement

RFC 5280 [4.2.1.3]

id-ce-keyUsage OBJECT IDENTIFIER ::= id-ce 15

  • Bitstring es hexadecimal

      KeyUsage ::= BIT STRING 
      digitalSignature    (0),
      nonRepudiation      (1),
      keyEncipherment     (2),
      dataEncipherment    (3),
      keyAgreement        (4),
      keyCertSign         (5),
      cRLSign             (6),
      encipherOnly        (7),
      decipherOnly        (8)

ExtendedKeyUsage

serverAuth

  • Todos los servidores VPN deben estar firmados con este EKU presente
    • EKU de autenticación de servidor web / VPN SSL / TLS, que distingue un servidor contra el que los clientes pueden autenticarse
    • Esto reemplaza nscertype opciones (ns en nscertype significa NetScape [browser])
    • Req. KU:digitalSignature, keyEncipherment o keyAgreement

clientAuth

  • Todos los clientes VPN deben estar firmados con este EKU presente
    • Autenticación de cliente SSL / TLS Web / VPN EKU que distingue a un cliente solo como cliente
    • Req. KU:digitalSignature y / o keyAgreement

codeSigning

  • Firma de código
    • Req. KU:digitalSignature, nonRepudiationy / o keyEncipherment o keyAgreement

emailProtection

  • Protección de correo electrónico a través de S / MIME, le permite enviar y recibir correos electrónicos encriptados
    • Req. KU:digitalSignature, keyEncipherment o keyAgreement

timeStamping

  • Sellado de tiempo de confianza
    • Req. KU:digitalSignature, nonRepudiation

OCSPSigning

  • Firma de OCSP
    • Req. KU:digitalSignature, nonRepudiation

msCodeInd

  • Firma de código individual de Microsoft (authenticode)
    • Req. KU:digitalSignature, keyEncipherment o keyAgreement

msCodeCom

  • Firma de código comercial de Microsoft (authenticode)
    • Req. KU:digitalSignature, keyEncipherment o keyAgreement

mcCTLSign

  • Firma de listas de confianza de Microsoft
    • Req. KU:digitalSignature, nonRepudiation

msEFS

  • Firma del sistema de archivos cifrados de Microsoft
    • Req. KU:digitalSignature, keyEncipherment o keyAgreement

!!! NO SE DEBE UTILIZAR !!!

ipsecEndSystem, ipsecTunnelY ipsecUser

  • Asignados en 1999, la semántica de estos valores nunca se definió claramente
  • RFC 4945: El uso de estos tres valores EKU está obsoleto y explícitamente desaprobado por esta especificación. [5.1.3.12]

ipsecIKE

  • Intercambio de claves de Internet IPSec
  • Creo que esto está en el mismo barco que los tres anteriores.
    • Es necesario realizar una investigación para determinar si esta EKU tampoco debe utilizarse más.
  • clientAuth se puede utilizar en un certificado de cliente VPN IPSec

RFC 5280 [4.2.1.12]

anyExtendedKeyUsage OBJECT IDENTIFIER ::= id-ce-extKeyUsage 0

  • id-kp OBJECT IDENTIFIER ::= id-pkix 3

    • id-kp-serverAuth OBJECT IDENTIFIER ::= id-kp 1

      • Autenticación del servidor TLS
        • Bits KU para:
          digitalSignature, keyEncipherment o keyAgreement

    • id-kp-clientAuth OBJECT IDENTIFIER ::= id-kp 2

      • Autenticación de cliente TLS
        • Bits KU para:
          digitalSignature y / o keyAgreement

    • id-kp-codeSigning OBJECT IDENTIFIER ::= id-kp 3

      • Firma de código ejecutable descargable
        • Bits KU para:
          digitalSignature

    • id-kp-emailProtection OBJECT IDENTIFIER ::= id-kp 4

      • Protección de correo electrónico
        • Bits KU para:
          digitalSignature, nonRepudiationy / o keyEncipherment o keyAgreement

    • id-kp-timeStamping OBJECT IDENTIFIER ::= id-kp 8

      • Vinculando el hash de un objeto a un tiempo
        • Bits KU para:
          digitalSignature y / o nonRepudiation

    • id-kp-OCSPSigning OBJECT IDENTIFIER ::= id-kp 9

      • Firma de respuestas OCSP
        • Bits KU para:
          digitalSignature y / o nonRepudiation

Cualquier certificado de CA, no importa si es raíz o intermedio, debe tener la keyCertSign extensión. Si también desea firmar una lista de revocación (CRL) con el certificado de CA (generalmente lo desea), debe agregar cRLSign así como. Cualquier otro keyUsages puede y debe evitarse para los certificados de CA.

La lista de valores aceptados por openssl se documenta aquí.

Para los certificados de entidad final, puede usar cualquiera de los otros keyUsages documentados por openssl, solo asegúrese de no incluir las extensiones de CA mencionadas anteriormente. Desde una perspectiva de seguridad, no debe usar más keyUsages de los necesarios (especialmente se recomienda usar certificados separados para la firma y el cifrado), pero ese no es un requisito estricto.

Tenga en cuenta que, además de los clásicos keyUsages, también existe el extendedKeyUsage (EKU), que no se limita a valores predefinidos en el RFC, pero teóricamente puede contener cualquier OID que desee. Los valores conocidos son, por ejemplo, certificados para firmar marcas de tiempo o respuestas OCSP.

No necesitas usar nsCertType. Esas, junto con todas las demás extensiones ns *, fueron definidas por Netscape hace mucho tiempo y ya no deberían usarse. Probablemente no encontrará ningún software todavía usándolos.

A para otras extensiones, lo único absolutamente necesario es el basicConstraints extensión que tiene un booleano CA bandera que debe establecer en consecuencia. Las extensiones AuthorityKeyIdentifier y subjectkeyIdentifier también son muy recomendadas.

Sección de Reseñas y Valoraciones

Si guardas alguna indecisión y capacidad de regenerar nuestro sección puedes añadir una crónica y con placer lo leeremos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)

Tags : / / /

Utiliza Nuestro Buscador

Preguntas Relacionadas:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *