Conteúdo
Aplicativos Instalados:
make-ca
Diretórios Instalados:
/etc/ssl/{certs,local} e
/etc/pki/{nssdb,anchors,tls/{certs,java}}
make-ca-1.14
Introdução ao make-ca
A Infraestrutura de Chave Pública (ICP) é um método para validar a autenticidade de uma entidade desconhecida ao longo de redes de comunicação não confiáveis. A ICP funciona estabelecendo uma cadeia de confiança, em vez de confiar explicitamente em cada dispositivo individual ou entidade. Para a finalidade de um certificado apresentado por uma entidade remota ser acreditado, esse certificado precisa apresentar uma cadeia completa de certificados que possa ser validada usando-se o certificado raiz de uma Autoridade Certificadora (AC) que é acreditada pela máquina local.
Estabelecer confiança com uma AC envolve validar coisas como endereço da companhia, titularidade de propriedade, informação de contato, etc., e assegurar que a AC tenha seguido as melhores práticas, tais como se submeter a auditorias periódicas de segurança por investigadores(as) independentes e manter uma sempre disponível lista de revogação de certificado. Isso está bem fora do escopo do BLFS (como está para a maior parte das distribuições do Linux). A loja de certificado fornecida aqui é tomada a partir da Fundação Mozilla, que estabeleceu políticas de inclusão muito estritas descritas aqui.
Esse pacote é conhecido por construir e funcionar corretamente usando uma plataforma LFS 12.2.
Informação do Pacote
-
Transferência (HTTP): https://github.com/lfs-book/make-ca/archive/v1.14/make-ca-1.14.tar.gz
-
Tamanho da transferência: 40 KB
-
Somas de verificação MD5 da transferência: e99d2985ead0037caedb765fd66b33f0
-
Espaço em disco estimado exigido: 164 KB (com todas as dependências em tempo de execução)
-
Tempo de construção estimado: 0,1 UPC (com todas as dependências em tempo de execução)
![[Nota]](../images/note.png)
Nota
Esse pacote envia um certificado de AC para validar a identidade
de https://hg.mozilla.org/. Se a
cadeia de confiança desse sítio da web tiver sido mudada depois
do lançamento do make-ca-1.14, ele poderá falhar ao obter a
revisão do certdata.txt a partir do
servidor. Use uma versão atualizada do make-ca na página de
lançamento se esse problema ocorrer.
Dependências do make-ca
Exigidas
p11-kit-0.25.5 (tempo de execução, construído depois do libtasn1-4.19.0, exigido nas instruções a seguir para gerar armazenamentos de certificados a partir de âncoras de confiança, e a cada vez que make-ca for executado)
Opcionais (tempo de execução)
nss-3.103 (para gerar um NSSDB compartilhado)
Instalação do make-ca e Geração dos Armazenamentos de Certificados de AC
O script make-ca baixará e
processará os certificados incluídos no arquivo certdata.txt para uso como âncoras de confiança
para o módulo de confiança p11-kit-0.25.5. Adicionalmente, gerará
lojas de certificado do sistema usadas pelos aplicativos do BLFS
(se os aplicativos recomendados e os opcionais estiverem presentes
no sistema). Quaisquer certificados locais armazenados em
/etc/ssl/local serão importados para
ambos: as âncoras de confiança; e as lojas de certificado geradas
(substituindo a confiança do Mozilla). Adicionalmente, quaisquer
valores de confiança modificados serão copiados a partir das
âncoras de confiança para /etc/ssl/local antes de quaisquer atualizações,
preservando os valores de confiança personalizados que divergirem
do Mozilla quando se usar o utilitário trust oriundo do p11-kit para operar sobre a loja de confiança.
Para instalar as várias lojas de certificados, primeiro instale o
script make-ca no local correto.
Como o(a) usuário(a) root:
make install && install -vdm755 /etc/ssl/local
Nota
Tecnicamente, esse pacote já está instalado neste ponto. Mas, a maioria dos pacotes que listam make-ca como uma dependência na verdade exige a loja de certificados do sistema configurado por esse pacote, em vez do próprio programa make-ca. Portanto, as instruções para usar make-ca para configurar a loja de certificados do sistema estão incluídas nesta seção. Você deveria certificar-se de que a dependência de tempo de execução exigida para make-ca esteja satisfeita agora e continuar para seguir as instruções.
Como o(a) usuário(a) root, baixe o
fonte do certificado e apronte para uso do sistema com o seguinte
comando:
Nota
Se executar-se o script uma segunda vez com a mesma versão do
certdata.txt, por exemplo, para
atualizar as lojas quando o make-ca for atualizado; ou para acrescentar
lojas adicionais conforme o software solicitante for instalado,
[então] substitua a chave -g pela chave -r na linha de comando. Se
empacotando, [então] execute make-ca --help para ver todas
as opções de linha de comando disponíveis.
/usr/sbin/make-ca -g
Você deveria atualizar periodicamente a loja com o comando acima,
seja manualmente, ou via um temporizador do
systemd. Um temporizador está instalado em /usr/lib/systemd/system/update-pki.timer que, se
habilitado, verificará as atualizações semanalmente.
Execute os seguintes comandos, como
o(a) usuário(a) root, para
habilitar o temporizador do systemd:
systemctl enable update-pki.timer
Configurando make-ca
Para a maioria dos(as) usuários(as), nenhuma configuração adicional
é necessária; entretanto, o arquivo certdata.txt padrão fornecido pelo "make-ca" é
obtido a partir da ramificação "mozilla-release" e é modificado
para fornecer uma revisão "Mercurial". Essa será a versão correta
para a maior parte dos sistemas. Existem muitas outras variantes do
arquivo disponíveis para uso que poderiam ser preferidas por uma
razão ou por outra, incluindo os arquivos enviados com os produtos
da "Mozilla" neste livro. "RedHat" e "OpenSUSE", por exemplo, usam
a versão inclusa no nss-3.103. Transferências adicionais do(a)
desenvolvedor(a) estão disponíveis nos links inclusos em
/etc/make-ca/make-ca.conf.dist.
Simplesmente copie o arquivo para /etc/make-ca.conf e edite conforme apropriado.
Acerca de Argumentos de Confiança
Existem três tipos de confiança que são reconhecidos pelo script
make-ca, SSL/TLS, S/Mime e
assinatura de código. Para o OpenSSL, esses são serverAuth; emailProtection; e codeSigning, respectivamente. Se um
dos três argumentos de confiança for omitido, [então] o certificado
nem é acreditado, nem é rejeitado para aquela função. Os clientes
que usarem o OpenSSL ou o
NSS encontrando esse certificado
apresentarão um aviso para o(a) usuário(a). Os clientes usando o
GnuTLS sem o suporte ao
p11-kit não estão cientes dos
certificados confiáveis. Para incluir essa AC nos arquivos
ca-bundle.crt, email-ca-bundle.crt ou objsign-ca-bundle.crt (os pacotes legados do
GnuTLS), precisa ter os argumentos
confiáveis adequados.
Acrescentando Certificados Adicionais de AC
O diretório /etc/ssl/local está
disponível para acrescentar certificados adicionais de AC à loja de
confiança do sistema. Esse diretório também é usado para armazenar
certificados que foram acrescentados a ou modificados na loja de
confiança do sistema pelo p11-kit-0.25.5, de forma que os valores
de confiança sejam mantidos ao longo de atualizações. Os arquivos
nesse diretório precisam estar no formato de certificado confiável
do OpenSSL. Os certificados
importados usando o utilitário trust originário do p11-kit-0.25.5 utilizarão os valores Uso
Estendido de Chave x509 para atribuir valores confiáveis padrão
para as âncoras do sistema.
Se você precisar substituir os valores de confiança ou, do
contrário, precisar criar um certificado de confiança do
OpenSSL manualmente a partir de um
arquivo codificado PEM comum, [então] você precisa acrescentar
argumentos de confiança ao comando openssl e criar um certificado
novo. Por exemplo, usando as raízes do CAcert, se você quiser confiar em
ambos para todas as três funções, [então] os seguintes comandos
criarão os certificados confiáveis do OpenSSL adequados (execute
como o(a) usuário(a) root depois
que o Wget-1.24.5 estiver instalado):
wget http://www.cacert.org/certs/root.crt &&
wget http://www.cacert.org/certs/class3.crt &&
openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 1 root" \
-addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
> /etc/ssl/local/CAcert_Class_1_root.pem &&
openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert Class 3 root" \
-addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
> /etc/ssl/local/CAcert_Class_3_root.pem &&
/usr/sbin/make-ca -r
Substituindo a Confiança do Mozilla
Ocasionalmente, possivelmente existam instâncias onde você não
concorda com a inclusão do Mozilla de uma autoridade de
certificação específica. Se você gostaria de substituir a confiança
padrão de uma AC específica, [então] simplesmente crie uma cópia do
certificado existente em /etc/ssl/local com argumentos de confiança
diferentes. Por exemplo, se você gostaria de desconfiar do arquivo
"Makebelieve_CA_Root", [então] execute os seguintes comandos:
openssl x509 -in /etc/ssl/certs/Makebelieve_CA_Root.pem \
-text \
-fingerprint \
-setalias "Disabled Makebelieve CA Root" \
-addreject serverAuth \
-addreject emailProtection \
-addreject codeSigning \
> /etc/ssl/local/Disabled_Makebelieve_CA_Root.pem &&
/usr/sbin/make-ca -r
Usando make-ca com Python3
Quando Python3 foi instalado no LFS, ele incluiu o módulo pip3 com certificados vendidos originários do módulo Certifi. Isso era necessário, mas significa que sempre que pip3 for usado, ele pode referenciar esses certificados, principalmente ao criar um ambiente virtual ou ao instalar um módulo com todas as dependências wheel dele de uma vez.
Geralmente considera-se que o(a) Administrador(a) do Sistema(a) deveria ser responsável por quais certificados estão disponíveis. Agora que make-ca-1.14 e p11-kit-0.25.5 foram instalados e make-ca foi configurado, é possível fazer com que pip3 use os certificados do sistema.
Os certificados fornecidos instalados no LFS são um instantâneo de quando a versão extraída do Certifi foi criada. Se você atualizar regularmente os certificados do sistema, [então] a versão fornecida se tornará desatualizada.
Para usar os certificados do sistema no Python3, você deveria configurar _PIP_STANDALONE_CERT para apontar para eles, por
exemplo, para o shell bash:
export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt
![[Atenção]](../images/warning.png)
Atenção
Se você tiver criado ambientes virtuais, por exemplo, ao testar
módulos, e eles incluem os módulos Requests e Certifi em ~/.local/lib/python3.12/, então esses módulos
locais serão usados em vez dos certificados do sistema, a menos
que você remova os módulos locais.
Para usar os certificados do sistema no Python3 com os perfis BLFS, adicione a seguinte variável aos teus perfis de sistema ou pessoal:
mkdir -pv /etc/profile.d &&
cat > /etc/profile.d/pythoncerts.sh << "EOF"
# Inicia /etc/profile.d/pythoncerts.sh
export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt
# Termina /etc/profile.d/pythoncerts.sh
EOF