Cifra la llave privada (.key/.pfx) y la contraseña de tu e.firma (FIEL) en tu propio equipo, con el estándar abierto JWE (RSA-OAEP-256 + A256GCM), antes de enviarlas a SatGo. Así viajan siempre cifradas y SatGo solo las descifra en memoria, en el instante de usarlas.
Cuando integras la e.firma (FIEL) del SAT con la API de SatGo por la vía de transmisión directa, normalmente envías el archivo .key (o .pfx) y su contraseña en cada petición. SatGo los usa solo en memoria y los descarta al terminar, pero puedes agregar una capa extra: cifrarlos tú mismo, antes de que salgan de tu equipo.
Para eso, SatGo publica una llave pública RSA. Con ella cifras la llave privada y la contraseña como dos JWE compactos independientes (RFC 7516) usando RSA-OAEP-256 para envolver la llave de contenido y A256GCM para cifrar los datos. Solo la llave privada de cifrado de SatGo —que vive en su propio Azure Key Vault y nunca sale de ahí— puede abrir ese sobre. El certificado .cer es información pública del SAT y siempre se envía en claro.
Es opcional y complementario: si además quieres que tu llave privada nunca salga de tu infraestructura, la alternativa es el modelo BYOK con tu propio Azure Key Vault — ver la guía paso a paso. El cifrado JWE de esta página es para cuando sigues enviando la e.firma a SatGo, pero quieres que viaje siempre cifrada.
Elige la que mejor se adapte a tu flujo: desde el navegador si lo haces manualmente, o desde línea de comandos si quieres automatizarlo en un script o backend propio.
La forma más sencilla, sin instalar nada. En el Playground de SatGo Web, dentro de Credenciales de autenticación → FIEL, activa la casilla “Cifrar e.firma (recomendado)” y sube tu .key y contraseña.
Para automatizar el cifrado en un script, pipeline o tu propio backend, sin depender de un navegador. Es un ejecutable para Windows (requiere el runtime de .NET 10) que cifra 100% en tu equipo — ningún comando envía información por red, y nunca necesita credenciales tuyas ni de SatGo.
Camino más rápido: el mismo repositorio ya incluye la llave pública de SatGo como archivo fiel-enc-prod.pub.pem junto al ejecutable, así que puedes descargarlo y cifrar de una vez, sin llamar primero al endpoint. Conserva los cinco archivos de la carpeta juntos.
Cifra tu llave y contraseña usando ese fiel-enc-prod.pub.pem del repositorio:
# Cifrar la llave .key (o .pfx) → JWE .\FielEncryptClient.exe encrypt --pem fiel-enc-prod.pub.pem \ --infile fiel.key --outfile llave.jwe # Cifrar la contraseña → JWE .\FielEncryptClient.exe encrypt --pem fiel-enc-prod.pub.pem \ --intext "mi-password"
Si prefieres no depender del archivo del repositorio (por ejemplo, para detectar una futura rotación de la llave), puedes obtenerla en cualquier momento desde la API en su lugar, con el parámetro --pemtext:
curl -H "Authorization: Bearer {tu_jwt}" \
https://api.sat-go.com/api/v1/secretprovider/fiel-encryption-keyY usar el campo publicKeyPem de la respuesta, guardado como archivo o pasado directo con --pemtext.
Sea cual sea la vía que uses para cifrar, el resultado se envía igual: la llave cifrada como el contenido del campo llavePrivada, la contraseña cifrada como texto en Contrasena, el certificado .cer sin cifrar en Certificado, y agregando el header:
X-Fiel-Encryption: JWE
Con ese header, cualquier endpoint que acepte e.firma en la API de SatGo (descarga masiva de CFDI, opinión de cumplimiento, constancia fiscal, declaraciones, etc.) acepta la llave y contraseña cifradas en lugar de en claro. El contrato completo del campo y ejemplos de request están en la referencia de GET /secretprovider/fiel-encryption-key en la documentación de la API.
Un mismo endpoint, por ejemplo POST /api/v2/consultar/csffiel (descarga la Constancia de Situación Fiscal con FIEL), luce así en ambos casos:
Sin cifrar — llave y contraseña en claro
curl -X POST "https://api.sat-go.com/api/v2/consultar/csffiel" \
-H "Authorization: Bearer {tu_jwt}" \
-H "RFC: XAXX010101000" \
-F "Certificado=@fiel.cer" \
-F "llavePrivada=@fiel.key" \
-F "Contrasena=mi-password" \
-o constancia.pdfCifrado (JWE) — llave y contraseña cifradas, header X-Fiel-Encryption
curl -X POST "https://api.sat-go.com/api/v2/consultar/csffiel" \
-H "Authorization: Bearer {tu_jwt}" \
-H "RFC: XAXX010101000" \
-H "X-Fiel-Encryption: JWE" \
-F "Certificado=@fiel.cer" \
-F "llavePrivada=@llave.jwe" \
-F "Contrasena=eyJhbGciOiJSU0EtT0FFUC0yNTYi...(JWE compacto)" \
-o constancia.pdfLa única diferencia: el header X-Fiel-Encryption: JWE, el contenido del campo llavePrivada (JWE en vez de los bytes del .key) y el de Contrasena (JWE en vez de texto plano). El certificado .cer y el resto de headers no cambian.
No. Es una capa de seguridad opcional. Puedes seguir enviando tu .key/.pfx y contraseña directamente (SatGo los usa solo en memoria y nunca los persiste), o activar el cifrado JWE para que ni siquiera viajen en claro por la red. También puedes optar por el modelo BYOK, donde la llave privada nunca sale de tu propio Azure Key Vault.
JWE (JSON Web Encryption) compacto, con el par de algoritmos RSA-OAEP-256 para cifrar la llave de contenido y A256GCM para cifrar los datos. Es un estándar abierto (RFC 7516), no un formato propietario de SatGo.
Se cifran la llave privada (.key o .pfx) y la contraseña de la e.firma. El certificado (.cer) es información pública del SAT y siempre se envía en claro, igual que el RFC.
No si usas el Playground de SatGo Web: el cifrado corre en tu navegador con Web Crypto y descargas la llave cifrada con un clic. Si prefieres automatizarlo desde un script o pipeline, puedes usar la herramienta de línea de comandos FielEncryptClient sin depender del navegador.
No. Solo la llave privada de cifrado de SatGo, resguardada en su propio Azure Key Vault, puede abrir el JWE, y solo lo hace en memoria en el instante de usar la e.firma. Ningún proxy, log o sistema intermedio ve el contenido en claro.