Você tem razão em se preocupar com a "assinatura de CRL", "CA de qualquer finalidade" e "Ajudante de OCSP". Normalmente, eles são reservados para certificados de CA ou certificados especificamente emitidos para assinar listas de revogação de certificados (CRLs, uma lista de certificados inválidos) ou executando um servidor OCSP (semelhante a CRLs, mas um serviço online que fornece status de validade para certificados).
A página de documentação relevante do OpenSSL é para o comando x509 e x509v3_config
Aqui está a configuração do OpenSSL que uso para gerar certificados de clientes:
[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
Eu vou guiá-lo por linha a linha:
O basicConstraints está definido como crítico, o que significa "rejeitar este certificado se você não entender esse bit" e especifica que o certificado é não uma CA . Mesmo que alguém use software para emitir um certificado deste certificado, nunca será confiável.
O uso estendido da chave não é essencial, mas alguns softwares exigem que ele esteja presente e tenha uma finalidade específica listada. Isso lista a autenticação do cliente (do que você está falando) e também a assinatura e-mail do S / MIME & criptografia; você pode remover com segurança o propósito S / MIME se não precisar dele.
subjectAltName permite incluir informações sobre o assunto que você não pode incluir no campo subject . Ele também é usado em certificados de servidor da Web para incluir nomes de domínio para os quais o certificado pode ser usado, diferente do domínio especificado no atributo de nome comum do assunto; esses certificados são referidos como certificados SAN (nome alternativo da entidade). É prática comum incluir o endereço de email no subjectAltName em vez do assunto; você não precisa incluir um endereço de e-mail e pode omitir a extensão.
crlDistributionPoints lista os locais em que a CRL da autoridade de emissão está disponível; ele informa ao software que está tentando validar o certificado "aqui é onde ir para ver se esse certificado ainda é válido". Para uso na Internet, uma http:// URL é provavelmente a melhor (as CRLs são assinadas digitalmente, portanto, não há necessidade de https e isso pode causar problemas de loop de confiança).
authorityKeyIdentifier é geralmente o hash SHA-1 da chave pública da CA de emissão (embora possa haver outros valores). Se você incluir essa extensão, o valor deverá corresponder ao valor de subjectKeyIdentifier no certificado da CA de emissão .
authorityInfoAccess é um pouco como crlDistributionPoints , mas especifica onde obter o certificado CA em vez da CRL. Isso é útil se você tiver uma longa cadeia de confiança: por exemplo, O CA-1 emite o CA-2, que emite o CA-3, que emite o certificado; o software que tenta verificar o certificado pode usar essa extensão para obter o certificado CA-3 e usar o valor desse certificado para obter o certificado CA-2 etc. Geralmente, a cadeia de certificados (nesse caso, o certificado CA-2) e o certificado CA-3) é fornecido junto com o certificado do assunto (por exemplo, em uma transação SSL ou no email S / MIME). Não conheço nenhum software que use essa extensão, mas também não sei se é comumente usado. É comumente incluído em certificados.
De tudo isso, você só precisa de basicConstraints e extendedKeyUsage ; restrições básicas realmente, realmente devem ser críticas (ou você acabou de distribuir certificados de CA!), e o uso estendido de chaves geralmente não é.