Pular para o conteúdo

TLS e certificados

O Fetchpier traz sua própria configuração de confiança. O trust store do sistema operacional não é consultado de propósito, então uma raiz corporativa que vive apenas no keychain do SO precisa ser importada no Fetchpier antes que chamadas HTTPS para aquele ambiente funcionem.

Os certificados vivem em um de dois escopos:

  • Global do app — aplica-se a cada workspace desta máquina. Armazenado junto às demais settings do app.
  • Workspace — aplica-se apenas ao workspace aberto no momento. Armazenado dentro de .fetchpier/, então viaja com o workspace no Git.

Ambos os escopos são gerenciados pela mesma UI: uma aba Certificados no diálogo de Settings global e outra no de Settings do Workspace. Certificados CA e certificados de cliente são listados separadamente, cada um com toggles de habilitar/desabilitar, descrições e ações de apagar. Os metadados de correspondência de um certificado de cliente — padrão de host, porta — e sua passphrase podem ser editados no lugar; os arquivos do certificado em si são imutáveis, então trocá-los significa remover a entrada e adicionar uma nova.

Ao importar um arquivo de certificado, o Fetchpier o copia para o diretório canônico do escopo com um nome saneado e com hash por conteúdo — caminhos arbitrários do usuário nunca são armazenados, apenas nomes de arquivo. Isso significa que apagar um arquivo fora da app não corrompe as settings, e a pasta do workspace fica autocontida.

Cada CA habilitada é adicionada a um bundle que também inclui as raízes confiáveis padrão, e esse bundle é usado para cada requisição HTTPS. Várias CAs de ambos os escopos podem ser habilitadas ao mesmo tempo.

Um certificado de cliente é associado a um padrão de host (host literal ou wildcard de um rótulo como *.example.com) e uma porta opcional. Para cada requisição, o Fetchpier escolhe o único certificado que melhor corresponde por especificidade:

  1. host literal + porta explícita,
  2. host literal, qualquer porta,
  3. wildcard + porta explícita,
  4. wildcard, qualquer porta.

Dentro do mesmo nível, o escopo workspace ganha do escopo do app; empates restantes são resolvidos pela ordem do documento.

Os formatos suportados são PEM (cert + key) e PFX. A passphrase se comporta de forma diferente por escopo:

  • Certificados de escopo workspace: a passphrase pode ser um literal ou uma referência {{variable}} resolvida contra o ambiente ativo — plana, secreta, ou um override local por máquina —, exatamente como qualquer outro campo interpolável. Uma passphrase com valor secreto é descriptografada apenas no momento do envio e usada para o handshake; nunca viaja pela rede e não aparece em nenhum log, relatório ou snapshot de execução. O input se adapta ao que você digita: uma passphrase literal é uma credencial real, então é mascarada (cada caractere é exibido apenas brevemente enquanto você digita, para ajudar a confirmar o que foi inserido), enquanto uma referência {{…}} permanece visível — o nome da variável não é o segredo — com destaque de tokens e sugestão disparada por {{ dos nomes de variáveis do ambiente ativo, secretos incluídos por nome. Uma passphrase literal não vazia em um certificado de workspace mostra um aviso por linha: ela fica commitada em texto claro no arquivo de settings do workspace, e uma variável secreta é recomendada no lugar.
  • Certificados globais do app: a passphrase é apenas literal. Inserir uma referência {{…}} é rejeitado ao salvar, porque um certificado global do app tem escopo de máquina e sobrevive a qualquer workspace, então uma variável com escopo de workspace não poderia ser resolvida ali.

A composição de CA e a seleção de certificado de cliente acontecem independentemente de verifySsl estar ligado — desligar a verificação apenas relaxa o passo de verificação, não desabilita o material próprio.

Quando a URL de uma requisição muda, o painel de Settings por requisição pré-visualiza qual certificado de cliente (se houver) seria selecionado e de qual escopo, para você verificar seus matchers de host antes de enviar.