add https option for adapter-node

[Mlocik97]

Describe the problem

When we want to set https with adapter-node. Build created by adapter-node has no ability to use https, or provide certificate to it.

Describe the proposed solution

I suggest to expose https option, where we would be able to set certificate and key like this:

 https: {
                    cert: fs.readFileSync('./cert.crt'),
                    key: fs.readFileSync('./key.key'),
                }

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

[Karlinator]

Adapter-node uses Polka, which only uses the http module internally. However, as demonstrated here it is quite possible to wrap polka in an https server.

I propose doing that if a https object is passed in the adapter options.

I am, however, not sure how to do that. We could pass them on from the build options into '.svelte-kit/node/env.js' where the host and port config already go. Then the server could use that at runtime to either do or don't wrap polka in https.

We'll also need to figure out if certificate and key should be loaded and embedded at build time or only their paths (and then be loaded at runtime). Loading at build time requires rebuilding the app when renewing certificates, which is not ideal. Loading at runtime only requires a restart, but is more dependent on device configuration.

As a side note: in many (arguably most) settings, particularly production apps, there is likely already at least one layer of reverse proxy which can handle SSL termination.

[Conduitry]

There's another issue for exposing the underlying Polka handler instead of starting up the server with the Node adapter. I think that's the appropriate solution here. We want to encourage people to use a reverse proxy of some sort, which is going to be more performant and configurable than Node's HTTPS support.

[Mlocik97]

@Conduitry well, ofc, reverse proxy, but there are still use cases when You want HTTPS dirrectly in Your node app. Mainly when You deploy to "non trusted" environment, or where You are unable to configure reverse proxy. Also reverse proxy is good solution only, if there is not any "untrusted" node between Your app and reverse proxy. We had a long chatting on discord about this with @benmccann and Sankar.

[Karlinator]

I agree, in some (few) cases you will want https all the way in to the node server. Maybe even with reverse proxy in between (they usually can be configured to use TLS to backends/upstreams as well).

[dominikg]

there is some discussion around ssl for adapter-node here #462
and a lengthy discussion on discord about production use of preview command also with ssl https://discord.com/channels/457912077277855764/819723698415599626/870284200136282132 (it's a bit scattered, sorry, that was before threads were a thing).

Basically i don't think this should come built-in for adapter-node. The vast majority of users are better off with a reverse-proxy in front of kit+adapter-node, and those with more special requirements can easily fork adapter-node into a community supported adapter-node-ssl (which should come with a prominent description why it exists and who it is for).

[aradalvand]

+1 I found myself needing precisely this, currently the only option seems to be creating a custom server, which is a bit of a bummer.

As for the reverse proxy argument, you could very well have a reverse proxy that isn't located on the same network and communicates with your app via an untrusted channel like the internet (e.g. CDN edge servers), meaning you would still want secure (HTTPS) connections between those proxies and your application; but having to introduce another proxy on the same server just to enable HTTPS feels unideal, especially given that Node already has support for this and therefore not much needs to be done on the part of SvelteKit/adapter-node in order to support it out of the box.

So, there is certainly a valid use case for this.

And also regarding:

We'll also need to figure out if certificate and key should be loaded and embedded at build time or only their paths (and then be loaded at runtime). Loading at build time requires rebuilding the app when renewing certificates, which is not ideal. Loading at runtime only requires a restart, but is more dependent on device configuration.

It should obviously be loaded at runtime, most often you don't even have the certificates available at build time.