curl no Ubuntu: teste o cliente e a base de revogação
Uma base de revogação precisa chegar ao cliente que executa o trabalho. Este roteiro liga o binário do curl à coleta dos dados e ao resultado observado na conexão.
Read in EnglishPor Pentesty
Entenda o alcance antes de definir a mudança
O anúncio da equipe Ubuntu, de 10 de novembro de 2026, apresenta upki no curl do Ubuntu 26.10. Antes da primeira coleta, permanece o comportamento anterior; o timer agenda coletas a cada seis horas. A integração mais ampla ao OpenSSL no 27.04 é um plano.
O registro de implementação documenta o build com OpenSSL e as exclusões de s390x e i386 naquela integração. Antes de aplicar essa descrição ao ambiente, confirme arquitetura, origem do pacote e configuração efetiva. Um nome de distribuição no inventário não responde qual cliente uma aplicação executa.
Localize o cliente que faz a requisição
Escolha uma automação de negócio, como uma integração financeira, e identifique onde sua requisição sai. Registre a imagem, o usuário, o caminho encontrado por command -v curl e a saída de curl --version. A documentação do curl explica como essa saída apresenta as bibliotecas TLS; builds MultiSSL podem oferecer escolhas de backend.
Repita o levantamento dentro do runner ou contêiner utilizado em produção. A ferramenta disponível no terminal do administrador pode ser diferente da usada no agendamento. Se uma aplicação incorpora libcurl, peça ao responsável pelo artefato a identificação da biblioteca e da integração utilizada, sem inferir cobertura a partir do executável do sistema.
- Associe cada resultado ao serviço, à imagem e ao usuário examinados.
- Guarde a origem do pacote e diferencie componentes da distribuição de builds próprios.
- Defina quem repetirá a verificação quando a imagem ou o backend mudar.
Confira a coleta no contexto correto
Ter um pacote listado e ter dados utilizáveis são condições diferentes. O guia de empacotamento do upki descreve configuração por usuário antes da configuração do sistema, cache e servidor de coleta configurável. Verifique quais caminhos o usuário do job realmente utiliza e consegue ler.
No ambiente Ubuntu abrangido, examine o resultado de upki-fetch.service e o histórico do timer. A ação documentada para iniciar uma coleta é sudo systemctl start upki-fetch.service, a executar pelo processo de mudança da empresa. Depois, confira conclusão e dados disponíveis; ausência de mensagem no console não substitui a consulta ao resultado do serviço.
Defina um responsável por falhas de atualização, inclusive após troca de proxy, certificado de inspeção ou política de saída. Combine uma condição de alerta sobre a última coleta bem-sucedida e um procedimento para revisar dados antigos. Essas condições são uma proposta operacional, sem afirmar um prazo universal de atualização dos certificados.
Compare resultados e registre o motivo
Em homologação autorizada, compare uma conexão válida com o exemplo revogado https://revoked.badssl.com/ indicado pelo Ubuntu. Preserve comando, horário, saída de erro e contexto do cliente. A lista de erros do curl trata o código 60 como falha de autenticação do certificado; ele sozinho não identifica revogação.
Leia o motivo completo e investigue diferenças entre o controle válido e o teste revogado. Não desligue a validação para fazer o job passar. Se houver divergência, mantenha a decisão pendente até distinguir problemas de confiança, caminhos de configuração e comportamento do cliente.
Inclua um cenário de inicialização sem acesso à coleta e outro de atualização interrompida, ambos isolados. Registre o que acontece com dados ausentes ou antigos e quem decide sobre a execução do negócio. Este roteiro propõe verificações; a Pentesty não executou esses testes no ambiente do leitor.
Separe confiança pública e PKI privada
O projeto upki descreve revogação para autoridades publicamente confiáveis. O contrato do callback OpenSSL preserva a verificação anterior quando a cadeia não está coberta pelos dados. Portanto, documente separadamente a política de revogação da PKI privada.
O aceite de uma integração deve reunir cliente, dados e comportamento observado. A análise sobre responsabilidade por conexões ajuda a definir o dono dessa decisão; o roteiro de bibliotecas OpenSSL em execução aprofunda a ligação entre pacote e processo. Use esses registros para revisar exceções e repetir o teste depois de mudanças.
Perguntas frequentes
Instalar o pacote comprova a verificação de revogação?
Não. Examine o cliente executado, os dados que ele consegue utilizar e o resultado de um teste controlado. Registre as condições que ainda não foram verificadas.
Uma coleta agendada comprova que os dados chegaram?
Confira o resultado da execução, o acesso ao cache e as falhas registradas. A agenda indica uma tentativa prevista, enquanto o resultado permite avaliar o que ocorreu.
O teste público valida também a minha CA interna?
Não presuma essa cobertura. Defina um teste próprio para a cadeia interna e registre o mecanismo de revogação realmente usado pela aplicação.
Quando repetir a avaliação?
Após mudanças no pacote, imagem, usuário, backend ou caminho de coleta. Mantenha também uma revisão periódica proporcional à criticidade da integração.
Fontes e referências
- Ubuntu: anúncio do upki
- Launchpad: integração no curl
- curl: opções e erros
- upki: empacotamento e coleta
- upki: escopo do projeto
- upki: contrato OpenSSL
Análise original da Pentesty, publicada em 11 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.