EUtornei-me minha própria autoridade certificadoradepois de executar o tutorial em:https://jamielinux.com/docs/openssl-certificate-authority/
Criei um par raiz, criei um par intermediário e assinei um certificado de 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
emsquid3.conf
O Squid inicia muito 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 estará acessando a internet através do proxy acabo com um erro:
Eu o gero com base noSeção "Assinar certificados de servidor e cliente" que diz "Criar um certificado"
Afirma que se vou criar um certificado de cliente para autenticação, precisarei usar a extensão 'usr_crt' e então executo:
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
Não entendo por que estou recebendo a mensagem de erro número 2 do TXT_DB quando executo o comando como root (em outra máquina, é claro).
De acordo com o tutorial, devo conseguir alterar o nome comum durante esse processo.
Responder1
TXT_DB error number 2significa DB_ERROR_INDEX_CLASH.
Você tentou enviar um certificado para o banco de dados OpenSSL CA com o mesmo índice duas vezes.
A causa disso geralmente é o envio de um certificado ao banco de dados que contém o mesmo número de série ou o mesmo nome comum. Para este último, verifique a unique_subjectopção no intermediate/openssl.confarquivo, sobre a qual você pode ler em man ca.
O nome comum de um certificado de cliente pode ser qualquer coisa – seu nome, por exemplo.
O Nome Comum será especificado no intermediate/openssl.confarquivo. Ele pode ser configurado para solicitar valores ou ler valores do arquivo de configuração. Isso é controlado pela promptopção, sobre a qual você pode ler em man req.
Responder2
De acordo com o tutorial, devo conseguir alterar o Nome Comum durante este processo
Esse tutorial diz para você gerar uma nova chave com openssl genrsaE um novo CSR com openssl req -newE criar o certificado do CSR com openssl ca. (Embora, como muitas pessoas, diga erroneamente que um certificado é criado 'assinando o CSR'. A CA não assina o CSR. A CA assina o certificado, que criaparcialmente baseado ema RSE, mas é diferente da RSE. /desabafo)
Quando você gera um novo CSRvocê especifica o nome do assunto, incluindo, mas não se limitando ao Nome Comum, que, como diz, deve ser diferente dos certificados de CA acima dele, edevediferem de outros certificados EE para evitar confusão.
openssl cana verdade, pode substituir o nome do assunto de um certificado emitido (o nome completo, 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 preocupam com essa parte, outros se preocupam, então não é fácil).
Erro ao carregar a extensão na seção usr-crt
... sem valor ... name=email_in_dn
Isso pode vir de um arquivo de padrões upstream ...
Não diretamente. openssl ca -config xxxusa xxx, e apenas xxx, como arquivo de configuração. Se o seu arquivo for derivado do upstream, o nome da seção desejada é usr_certo que 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; depois de consertar, isso -noemailDNnão é necessário, embora você possa querer de qualquer maneira.
Isso tem algo a ver com subjectNameAlt?
Supondo que você queira dizer unique_subject, não. subjectAltName(não subjectNameAlt) também conhecido como SAN é uma extensão comum que especifica nomes alternativos para o assunto, mas unique_subjectrelaciona apenas o campo básico Subjecte não qualquer SAN.
certificado do lado do cliente para instalar em um navegador que acessará a internet através do proxy
Para ser claro, um certificado de cliente como este só é útil para se autenticarpara o procurador. Você não pode usar um certificado no cliente/navegador para autenticar algo na Internet através de QUALQUER MitM HTTPS e não pode usar um certificado de cliente emitido por você mesmo para autenticar o(s) sistema(s) de outra pessoa na Internet.