Skip to content

Conversation

@martiinii
Copy link

Fixes ERR_TLS_CERT_ALTNAME_INVALID when using Next.js with Bun.

When running Next.js under Bun, proxying via a catch-all route failed with ERR_TLS_CERT_ALTNAME_INVALID. Bun's TLS validation is stricter than Node's and will reject requests when the Host header does not match the target URL's hostname.

Root cause:
Our proxy forwarded the original request headers including host: localhost:3000 (from local dev server) to the upstream Convex URL. This mismatched host header triggered Bun's TLS altname check.

Example of forwarded headers prior to this change (from a local dev server):

{
    host: "localhost:3000",
    "user-agent":
        "Mozilla/5.0 (X11; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0",
    accept: "*/*",
    "accept-language": "en-US,en;q=0.5",
    "accept-encoding": "gzip, deflate, br, zstd",
    referer: "http://localhost:3000/auth/login",
    connection: "keep-alive",
    cookie: "xxx",
    "sec-fetch-dest": "empty",
    "sec-fetch-mode": "cors",
    "sec-gpc": "1",
    "sec-fetch-site": "same-origin",
    priority: "u=4",
    "x-forwarded-host": "localhost:3000",
    "x-forwarded-port": "3000",
    "x-forwarded-proto": "http",
    "x-forwarded-for": "::ffff:127.0.0.1",
}

This PR addresses this issue and removes host header before forwarding to Convex and lets fetch set the correct host based on the Convex URL.

Notes:
Other hop-by-hop headers could also be stripped but they have correct values for forwarded requests. They do not cause any issues though.

Links:


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@paschaldev
Copy link

Thank you for patching. Just hit this error @martiinii

// Delete `host` header that points to Next.js application address
// Bun TLS cert validation is more strict that Node.js and it
// detects mismatch between `host` header and the target URL causing `ERR_TLS_CERT_ALTNAME_INVALID`
headers.delete("host");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be a condition to check if the current runtime is bun and only do this for bun so it doesn't overwrite the efault node behaviour if things change in future

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This solution works with every JS runtime. If things were to change in the future, they would make TLS cert validation more secure in Node.js (just like Bun).
Also, regardless of JS runtime, the Host header was just straight wrong and should always be changed when proxying the request to another server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants