Ir al contenido

TLS y certificados

Fetchpier trae su propia configuración de confianza. El trust store del sistema operativo no se consulta a propósito, así que una raíz corporativa que vive solo en el keychain del SO hay que importarla a Fetchpier antes de que las llamadas HTTPS a ese entorno funcionen.

Los certificados viven en uno de dos ámbitos:

  • Global de la app — aplica a cada workspace de esta máquina. Se guarda junto al resto de los settings de la app.
  • Workspace — aplica solo al workspace abierto actualmente. Se guarda dentro de .fetchpier/, así viaja con el workspace en Git.

Ambos ámbitos se administran desde la misma UI: una pestaña Certificados en el diálogo de Settings global y otra en el de Settings del Workspace. Los certificados CA y los de cliente se listan por separado, cada uno con toggles de habilitar/deshabilitar, descripciones y acciones de eliminar. Los metadatos de coincidencia de un certificado de cliente —patrón de host, puerto— y su passphrase se pueden editar en el lugar; los archivos del certificado en sí son inmutables, así que cambiarlos significa quitar la entrada y agregar una nueva.

Al importar un archivo de certificado, Fetchpier lo copia al directorio canónico del ámbito con un nombre saneado y hasheado por contenido — nunca se guardan rutas arbitrarias del usuario, solo nombres de archivo. Esto significa que eliminar un archivo por fuera de la app no corrompe los settings, y la carpeta del workspace queda autocontenida.

Cada CA habilitada se agrega a un bundle que también incluye las raíces de confianza por default, y ese bundle se usa para cada request HTTPS. Se pueden habilitar varias CA de ambos ámbitos a la vez.

Un certificado de cliente se asocia a un patrón de host (host literal o wildcard de una etiqueta como *.example.com) y un puerto opcional. Para cada solicitud, Fetchpier elige el único certificado que mejor coincide por especificidad:

  1. host literal + puerto explícito,
  2. host literal, cualquier puerto,
  3. wildcard + puerto explícito,
  4. wildcard, cualquier puerto.

Dentro del mismo nivel, el ámbito workspace le gana al de la app; los empates restantes se resuelven por orden del documento.

Los formatos soportados son PEM (cert + key) y PFX. La passphrase se comporta distinto según el ámbito:

  • Certificados de ámbito workspace: la passphrase puede ser un literal o una referencia {{variable}} resuelta contra el entorno activo —plana, secreta, o un override local por máquina—, exactamente como cualquier otro campo interpolable. Una passphrase con valor secreto se desencripta solo en el momento del envío y se usa para el handshake; nunca viaja por la red y no aparece en ningún log, reporte ni snapshot de corrida. El input se adapta a lo que escribís: una passphrase literal es una credencial real, así que se enmascara (cada carácter se muestra solo brevemente mientras tipeás, para ayudarte a confirmar lo ingresado), mientras que una referencia {{…}} queda visible —el nombre de la variable no es el secreto— con resaltado de tokens y sugerencia disparada por {{ de los nombres de variables del entorno activo, secretos incluidos por nombre. Una passphrase literal no vacía en un certificado de workspace muestra una advertencia por fila: queda commiteada en texto claro en el archivo de settings del workspace, y se recomienda una variable secreta en su lugar.
  • Certificados globales de la app: la passphrase es solo literal. Ingresar una referencia {{…}} se rechaza al guardar, porque un certificado global de la app tiene alcance de máquina y sobrevive a cualquier workspace, así que una variable con alcance de workspace no podría resolverse ahí.

La composición de CA y la selección de certificado de cliente ocurren sin importar si verifySsl está activo — apagar la verificación solo relaja el paso de verificación, no desactiva el material propio.

Cuando cambia la URL de una solicitud, el panel de Settings por solicitud previsualiza qué certificado de cliente (si hay) se elegiría y desde qué ámbito, así podés verificar tus matchers de host antes de enviar.