Como configurar corretamente a CA openssl para gerar certificados de cliente SSL

8

Estou configurando minha primeira CA. O objetivo será emitir certificados para nossos clientes, que os usarão para acessar nosso serviço de EDI por meio de https. Então eu preciso gerar certificados de cliente SSL. Todo o processo de assinatura de certificados funciona até agora, e os certificados podem ser usados com sucesso para acessar nosso serviço, mas estou preocupado com uma coisa:

Os objetivos do certificado gerado são 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

Eu sinto que não deve haver outros propósitos além do cliente SSL e da assinatura S / MIME no meu caso. Estou errado e isso deve ficar como é?

Se eu estiver correto e precisar desativar outros propósitos, o que devo colocar na configuração do openssl.cnf?

Aqui está minha configuração atual (despojada um pouco):

[ 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

O que estou fazendo errado que os certs gerados permitem o uso do servidor?

    
por SWilk 12.07.2013 / 10:13

1 resposta

2

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 é.

    
por 16.10.2013 / 11:23

Tags