Cómo configurar correctamente CA OpenSL para generar certificados de cliente SSL

Estoy configurando mi primera CA. Su propósito será emitir certificados para nuestros clientes, quienes los usarán para acceder a nuestro servicio EDI a través de https. Entonces necesito generar certificados de cliente SSL. Todo el proceso de firma de certificados ya funciona, y los certificados se pueden usar con éxito para acceder a nuestro servicio, pero me preocupa una cosa:

Los propósitos del certificado generado son genéricos:

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

Siento que en mi caso no debería haber más propósitos que el cliente SSL y la firma S / MIME. ¿Me equivoco y esto debería quedar así?

Si estoy en lo correcto y debo deshabilitar otros propósitos, ¿qué debo poner en mi config de openssl.cnf?

Aquí está mi configuración actual (despojado un poco):

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

¿Qué estoy haciendo mal que los certificados generados permiten el uso del servidor?

Tiene derecho a preocuparse por la "firma de CRL", "CA de cualquier propósito" y "Ayudante de OCSP", estos generalmente están reservados para certificados de CA o certificados emitidos específicamente para firmar listas de revocación de certificados (CRL, una lista de certificados que son no válido) o ejecutando un servidor OCSP (similar a las CRL, pero un servicio en línea que proporciona el estado de validez de los certificados).

La página de documentación relevante de OpenSSL es para el comando x509 y x509v3_config

Aquí está la configuración de OpenSSL que uso para generar certificados de cliente:

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

Te guiaré línea por línea:

El basicConstraintsse fija como crítica, que significa "rechazan este certificado si usted no entiende este bit", y especifica que el certificado es no una CA . Incluso si alguien usa software para emitir un certificado de este certificado, nunca será confiable.

El uso de la clave extendida no es esencial, pero algunos softwares requieren que esté presente y tenga un propósito particular en la lista. Esto enumera la autenticación del cliente (de lo que está hablando) y también la firma y cifrado de correo electrónico S / MIME; puede eliminar con seguridad el propósito S / MIME si no lo necesita.

subjectAltNamele permite incluir información sobre el tema que no puede incluir en el subjectcampo. También se usa en los certificados de servidor web para incluir nombres de dominio para los que el certificado puede usarse para otros que no sean el dominio especificado en el atributo de nombre común del sujeto; Estos certificados se denominan certificados SAN (nombre alternativo del sujeto). Es una práctica común incluir la dirección de correo electrónico subjectAltNameen el asunto y no en el asunto; no tiene que incluir una dirección de correo electrónico y puede omitir la extensión.

crlDistributionPointsenumera los lugares donde está disponible la CRL para la autoridad emisora; le dice al software que está tratando de validar el certificado "aquí es a dónde ir para ver si este certificado aún es válido". Para el uso de Internet, una http://URL es probablemente la mejor (las CRL están firmadas digitalmente, por lo que no es necesario httpsy puede causar problemas de bucle de confianza).

authorityKeyIdentifiersuele ser el hash SHA-1 de la clave pública de la CA emisora ​​(aunque pueden ser otros valores). Si incluye esta extensión, el valor debe coincidir con el valor del subjectKeyIdentifiercertificado de CA emisor .

authorityInfoAccesses un poco parecido crlDistributionPointspero especifica dónde obtener el certificado de CA emisor en lugar de la CRL. Esto es útil si tiene una larga cadena de confianza: por ejemplo, CA-1 emite CA-2, que emite CA-3, que emite el certificado; el software que intenta verificar el certificado puede usar esta extensión para obtener el certificado CA-3, luego usar el valor en ese certificado para obtener el certificado CA-2, etc. Por lo general, la cadena de certificados (en este caso, el certificado CA-2 y certificado CA-3) se incluye junto con el certificado del sujeto (por ejemplo, en una transacción SSL o correo electrónico S / MIME). No conozco ningún software que use esta extensión, pero tampoco sé que tampoco se usa comúnmente. Se incluye comúnmente en los certificados.

De todo eso, solo necesitas realmente el basicConstraintsy extendedKeyUsage; las restricciones básicas realmente, realmente deben ser críticas (¡o acabas de entregar certificados CA!), y el uso extendido de claves generalmente no lo es.