Can't proxy to a server that uses a self-signed certificate

[seyoon20087]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022
    Binaries:
      Node: 18.15.0
      npm: 9.5.0
      Yarn: 1.22.19
      pnpm: 7.30.0
    Relevant packages:
      next: 13.3.1-canary.2
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue

https://github.com/seyoon20087/next-proxy-self-signed-certificate-error-reproduction

To Reproduce

Note: I tested this on Gitpod but the following steps might work on other systems, as long as the host OS is based on Unix (i.e. not Windows without a WSL environment).

1. Clone the repo above
2. Run yarn install
3. Run yarn dev
4. Open http://localhost:3000/c to see whether errors are being observed in the /c route
5. Also run it with NODE_TLS_REJECT_UNAUTHORIZED environment variable to 0

Describe the Bug

Maybe relevant to #45743 ; however that was closed already, so I am recreating an issue with a reproduction.

Some developers want to connect to a server that uses a self-signed certificate (only in dev-mode). However, this doesn't work even if NODE_TLS_REJECT_UNAUTHORIZED is set to 0.

If I attempt to do that, whether NODE_TLS_REJECT_UNAUTHORIZED is set to 0 or not, it ends up with the following:

$ yarn dev
# ... [truncated]
Failed to proxy https://[self-signed-certificate-server]/ Error: self-signed certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1540:34)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket.emit (node:domain:489:12)
    at TLSSocket._finishInit (node:_tls_wrap:959:8)
    at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:743:12) {
  code: 'DEPTH_ZERO_SELF_SIGNED_CERT'
}
error - Error: self-signed certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1540:34)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket.emit (node:domain:489:12)
    at TLSSocket._finishInit (node:_tls_wrap:959:8)
    at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:743:12) {
  code: 'DEPTH_ZERO_SELF_SIGNED_CERT'
}

I'm not sure if this is the intentional behavior on Next.js itself.

Expected Behavior

I expected the error above to NOT happen (and Node.js would allow to be connected to that server).

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[seyoon20087]

bump

[timneutkens]

Converted to discussions as this doesn't seem related to Next.js, we use http-proxy.

[beary]

Can next add a secure parameter to pass to http-proxy?

http-party/node-http-proxy#1638
I've create a MR to http-proxy, But I don't think they will deal with it soon because latest commit is three years ago.😢

[VakarisZ]

@timneutkens Any updates on this? Seems like a pretty simple PR. Need help?

[dbalatero]

@timneutkens It is related, as the API provided around http-proxy by Next.js is not flexible enough for the very common use case of proxying a local API server.

Ask: I provided 3 options to move forward below, do you mind commenting on which ones you might prefer as a maintainer?

What people want to do

async rewrites() {
  // Proxy https://localhost:3000/api/foo/bar -> https://localhost:8000/foo/bar
  return [
    {
      source: '/api/:path*',
      destination: `https://localhost:8000/:path*`,
    },
  ]
}

Out of the box, this breaks due to self-signed certificates not being allowed.

You can see here that if you don't pass secure: true to http-proxy, it defaults to secure: true.

And you can see here that the secure option is not passed by Next.js, so everyone is hard-opted into SSL certificate verification, even for the common use case of localhost https servers:

next.js/packages/next/src/server/lib/router-utils/proxy-request.ts

Lines 23 to 34 in da616e5

	const proxy = new HttpProxy({
	target,
	changeOrigin: true,
	ignorePath: true,
	ws: true,
	// we limit proxy requests to 30s by default, in development
	// we don't time out WebSocket requests to allow proxying
	proxyTimeout: proxyTimeout === null ? undefined : proxyTimeout || 30_000,
	headers: {
	'x-forwarded-host': req.headers.host || '',
	},
	})

Option 1: Turn off cert verification in development

The easiest change to make would be:

  const proxy = new HttpProxy({
    target,
    changeOrigin: true,
    ignorePath: true,
    ws: true,
    // we limit proxy requests to 30s by default, in development
    // we don't time out WebSocket requests to allow proxying
    proxyTimeout: proxyTimeout === null ? undefined : proxyTimeout || 30_000,
    headers: {
      'x-forwarded-host': req.headers.host || '',
    },
+   secure: process.env.NODE_ENV !== 'development',
  })

so TLS cert verification is default on in production, but off in development.

Option 2: Add a new field to the rewrites() api:

Add an optional config field to turn off TLS certificate checking (call it whatever):

async rewrites() {
  // Proxy https://localhost:3000/api/foo/bar -> https://localhost:8000/foo/bar
  return [
    {
      source: '/api/:path*',
      destination: `https://localhost:8000/:path*`,
+      verifyTLSCertificates: false,
    },
  ]
}

and thread this through to the new HTTPProxy(...) call, setting secure accordingly.

Option 3: Respect NODE_TLS_REJECT_UNAUTHORIZED

You could set secure based on this ENV variable, in case it's more palatable to do so:

  const proxy = new HttpProxy({
    target,
    changeOrigin: true,
    ignorePath: true,
    ws: true,
    // we limit proxy requests to 30s by default, in development
    // we don't time out WebSocket requests to allow proxying
    proxyTimeout: proxyTimeout === null ? undefined : proxyTimeout || 30_000,
    headers: {
      'x-forwarded-host': req.headers.host || '',
    },
+   secure: process.env.NODE_TLS_REJECT_UNAUTHORIZED !== '0',
  })

[rich-frost]

Are there any other suggestions on how we get around this issue developing locally?

[SD-Gaming]

Can we add a secure option?

In development, it is very common to use a self-signed certificate.

[hagaigold]

+1 for secure option

with express middleware something like this is doable:

const proxy = createProxyMiddleware({
    target: 'https://self-signed-certificate-server',
    //changeOrigin: true,
    secure: false,
    pathRewrite: { "^/api": "" }, // remove `/api` prefix
});`

[VakarisZ]

For anyone wondering, the only workaround I found is using ngrok. It's absurd that I have to use a third-party tool to work around the fact that there's no options for nextjs dev server to ignore certificate validation

[hagaigold]

For anyone wondering, the only workaround I found is using ngrok

Another option is to setup a local proxy on arbitrary port:

• run the proxy- node myproxy.js)
• call to your proxy from the application.

Something like that:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');

const proxy = createProxyMiddleware({
    target: 'https://self-signed-certificate-server',
    //changeOrigin: true,
    secure: false,
    pathRewrite: { "^/api": "" }, // remove `/api` prefix
});

const server = express();

// Proxy requests starting with '/api' to the target URL
server.use('/api', proxy);

server.get('/', function (req, res) {
  res.send('Hello World')
})

// Start the server
server.listen(3005, (err) => {
  if (err) throw err;
  console.log('> Ready on http://localhost:3005');
});

[VakarisZ]

To keep using nextjs server I set up middleware in /pages/api/[[...slug]].tsx file. You have to put the middleware in this dir to work even if you're using the app router. The contents are:

import type {NextApiRequest, NextApiResponse} from 'next';
import {createProxyMiddleware} from 'http-proxy-middleware';

const proxyMiddleware = createProxyMiddleware<NextApiRequest, NextApiResponse>({
    target: 'https://localhost:5000',
    secure: false,
    changeOrigin: true
});

export default function handler(req: NextApiRequest, res: NextApiResponse) {
    proxyMiddleware(req, res, (result: unknown) => {
        if (result instanceof Error) {
            throw result;
        }
    });
}

export const config = {
    api: {
        externalResolver: true,
        // Uncomment to fix stalled POST requests
        // https://github.com/chimurai/http-proxy-middleware/issues/795#issuecomment-1314464432
        bodyParser: false,
    },
};

[hagaigold]

Do you know if they will continue support Pages Router in future versions of NEXT.js?

[VakarisZ]

Maybe it's possible to rewrite this to use API routes. If we end up using next.js maybe we'll look into a better solution. Ultimately next.js team should finally respond to this issue and express their stance. Once it's agreed that it's next.js responsibility to pass secure option or respect the NODE_TLS_REJECT_UNAUTHORIZED we can create a PR. That's the actual solution

[addemod]

Pretty absurd that this is still not fixed..

[chanfi0ne]

💯

[dbalatero]

It's not necessarily on the maintainers to fix it, but anyone wanting to put up a PR is blocked by not having any guidance from maintainers as to what kind of solution they'd prefer.

[jt3k]

any updates ?

[rwarford]

Vite proxies allow redirecting to sites with self-signed certficates: see https://vite.dev/config/server-options#server-proxy. (Note that server.proxy extends http-proxy which has a "secure: false" option: https://github.com/http-party/node-http-proxy#options).
This is really helpful in development environments.

[astrodomas]

Hello, I want to ask is my issue the same #74187 ? Because my usecase would be to ignore tls on the server-side fetch (not middleware), direct call to my BE api layer.