Mensaje de error
self-signed certificate in certificate chain
También se muestra como
- code: 'SELF_SIGNED_CERT_IN_CHAIN'
- SELF_SIGNED_CERT_IN_CHAIN
Node.js 16 y anteriores (OpenSSL 1.1.1) lo escribían «self signed certificate in certificate chain». Con fetch() es la causa de «TypeError: fetch failed»; npm lo imprime como «npm error code SELF_SIGNED_CERT_IN_CHAIN».
Node.js tls / https / fetch — code SELF_SIGNED_CERT_IN_CHAIN (OpenSSL X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN, 19)
Qué significa
La cadena que envió el servidor termina en un certificado raíz autofirmado que no está entre las raíces en las que confía Node.js. En una red corporativa, esto lleva la firma de un proxy que inspecciona TLS: vuelve a firmar cada sitio con su propia raíz e incluye esa raíz en la cadena. Node.js usa su lista de raíces de Mozilla integrada, no el almacén del sistema operativo donde el departamento de TI instaló la raíz del proxy.
Por qué ocurre
Un proxy o un antivirus que inspecciona TLS
frecuenteZscaler, Netskope, Fortinet, Palo Alto y los antivirus que analizan el tráfico HTTPS presentan su propia raíz. Los navegadores confían en ella a través del almacén del sistema operativo; Node.js, de forma predeterminada, no.
Un servicio privado envía su propia raíz
frecuenteLos servidores internos que incluyen la raíz de la empresa en su cadena siguen necesitando que el cliente confíe en esa raíz; enviarla no demuestra nada.
La raíz está instalada en el sistema operativo, pero Node.js usa su propia lista
ocasionalNode.js incluye las raíces de Mozilla dentro del binario e ignora el almacén del sistema a menos que se indique --use-system-ca o se defina NODE_USE_SYSTEM_CA=1.
Cómo solucionarlo
- 1.
Ver quién emitió la cadena
Recorre la cadena de certificados que recibes de un sitio público. Si el certificado superior lleva el nombre de tu empresa o de un proveedor de seguridad, confía en esa raíz; si es desconocido, investiga antes de confiar en nada.
bash openssl s_client -connect registry.npmjs.org:443 -servername registry.npmjs.org -showcerts </dev/null 2>/dev/null \ | grep -E '^ *[0-9]+ s:|^ *i:' # The last line pair shows the root the chain ends in (s: and i: identical) - 2.
Añadir la raíz con NODE_EXTRA_CA_CERTS
Los certificados del archivo se añaden a las raíces integradas para todas las conexiones TLS del proceso, incluidas las de npm, yarn y fetch. Define la variable antes de que arranque el proceso.
bash export NODE_EXTRA_CA_CERTS=/etc/ssl/private-ca/corp-proxy-root.pem node app.js - 3.
Usar el almacén del sistema operativo
--use-system-ca o NODE_USE_SYSTEM_CA=1 hace que Node.js acepte las raíces en las que confía el sistema operativo, así que la raíz del proxy distribuida por el departamento de TI funciona sin copiar archivos.
bash # Managed machines already trust the proxy root in the OS store node --use-system-ca app.js NODE_USE_SYSTEM_CA=1 npm run build - 4.
Diagnóstico temporal: NODE_TLS_REJECT_UNAUTHORIZED=0
Desactiva la verificación de certificados para todo el proceso. Úsalo solo en una ejecución para confirmar la causa; detrás de un proxy que intercepta el tráfico, también oculta a cualquier atacante que no sea el proxy.
bash # Temporary diagnostic only: confirms trust is the only problem, then remove it NODE_TLS_REJECT_UNAUTHORIZED=0 node app.js