Não é possível gerar o certificado do lado do cliente depois de se tornar minha própria Autoridade de Certificação

3

Eu tornou-se minha própria autoridade de certificação depois de executar o tutorial em:

Eu criei um par raiz, criei um par intermediário e assinei um certificado do servidor, que instalei no squid assim:

http_port 3129 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/certs/gatesentry.csr.cert.pem key=/etc/squid3/key/gatesentry.key.pem

no squid3.conf

O Squid começa bem com isso. Ainda não tenho certeza se está realmente funcionando ou não.

Quando tento gerar um certificado do lado do cliente para instalar em um navegador que acessará a Internet por meio do proxy, acabo com um erro:

Eu o gero com base no " Assinar certificados de servidor e cliente "seção que diz" Criar um certificado "

Ele afirma que, se eu for criar um certificado de cliente para autenticação, precisarei usar a extensão 'usr_crt' para que eu execute:

cd /root/ca
openssl ca -config intermediate/openssl.conf \
      -extensions usr_cert -days 375 -notext -md sha256 \
      -in intermediate/csr/gatesentry.csr.pem \
      -out intermediate/certs/client.cert.pem
Using configuration from intermediate/openssl.conf
Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4097 (0x1001)
        Validity
            Not Before: Jun 22 10:36:44 2016 GMT
            Not After : Jul  2 10:36:44 2017 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Pennsylvania
            localityName              = locality
            organizationName          = Parents
            organizationalUnitName    = Security
            commonName                = gatesentry.domain.lan
            emailAddress              = [email protected]
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Client, S/MIME
            Netscape Comment: 
                OpenSSL Generated Client Certificate
            X509v3 Subject Key Identifier: 
                XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
            X509v3 Authority Key Identifier: 
                keyid:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, E-mail Protection
Certificate is to be certified until Jul  2 10:36:44 2017 GMT (375 days)
Sign the certificate? [y/n]: y
failed to update database
TXT_DB error number 2

Eu não entendo por que estou recebendo a mensagem número 2 do erro TXT_DB quando estou executando o comando como root (em outra máquina, é claro).

De acordo com o tutorial, eu deveria ser capaz de alterar o nome comum durante este processo.

    
por leeand00 22.06.2016 / 12:31

2 respostas

2

TXT_DB error number 2 significa DB_ERROR_INDEX_CLASH.

Você tentou enviar um certificado para o banco de dados do OpenSSL CA com o mesmo índice duas vezes.

A causa disso geralmente é enviar um certificado para o banco de dados que contém o mesmo Número de Série ou o mesmo Nome Comum. Para o último, verifique a opção unique_subject no arquivo intermediate/openssl.conf , sobre o qual você pode ler em man ca .

O nome comum para um certificado de cliente pode ser qualquer coisa - seu nome, por exemplo.

O nome comum será especificado no arquivo intermediate/openssl.conf . Pode ser configurado para solicitar valores ou ler valores do arquivo de configuração. Isso é controlado pela opção prompt , sobre a qual você pode ler em man req .

    
por 22.06.2016 / 14:02
1

According to the tutorial, I should be able to change the Common Name during this process

Esse tutorial diz para você gerar uma nova chave com openssl genrsa AND new CSR com openssl req -new AND criar o certificado do CSR com openssl ca . (Embora, como muitas pessoas, indique erradamente que um certificado é criado ao "assinar o CSR". O CA não assina o CSR. A CA assina o certificado, que cria parcialmente baseado em o CSR, mas é diferente do CSR. / rant)

Ao gerar um novo CSR , você especifica o nome do assunto, incluindo, entre outros, o nome comum, que, como diz, deve diferir dos certificados de AC acima, e deve diferir de outros certificados de EE para evitar confusão.

openssl ca pode, na verdade, substituir o nome da entidade para um certificado emitido (o nome inteiro, não o Nome comum individualmente), mas isso levará a certificados com nomes diferentes para a mesma chave, o que é, na melhor das hipóteses, desnecessariamente confuso e normalmente menos seguro (embora você não se importe com essa parte, outras o fazem, por isso não é fácil).

Error Loading extension in section usr-crt
... no value ... name=email_in_dn
Could this be coming from an upstream defaults file ...

Não diretamente. openssl ca -config xxx usa xxx e apenas xxx, como seu arquivo de configuração. Se o seu arquivo é derivado do upstream, o nome da seção que você deseja é usr_cert , como você aparentemente descobriu, mas você não precisa especificar usr_cert, porque é o padrão. A mensagem de erro sobre email_in_dn é apenas uma sobra na pilha de erros e o único erro real foi usr-crt ; uma vez que você consertar, -noemailDN não é necessário, embora você possa querer mesmo assim.

Does this have something to do with subjectNameAlt?

Assumindo que você quer dizer unique_subject , não. subjectAltName (não subjectNameAlt ) aka SAN é um comum extensão que especifica nomes alternativos para o assunto, mas unique_subject relaciona apenas o campo básico Subject não qualquer SAN.

client-side certificate to install in a browser that will be accessing the internet through the proxy

Para ser claro, um certificado de cliente como este é útil apenas para se autenticar no proxy . Você não pode usar um certificado no cliente / navegador para se autenticar em algo na Internet através de QUALQUER HTTPS MitM, e você não pode usar um certificado de cliente que você mesmo emite para autenticar no sistema de qualquer outra pessoa na Internet.

    
por 23.06.2016 / 15:32

Tags