React server side rendering: unable to verify the first certificate

[JoshClose]

I'm running on https. I can't seem to figure out why I'm getting this error. Everything looks roughly the same to me as the code generated from using yo to create a react/redux app. If I remove the [Authorize] app from the controller, the issue still happens. I've read this is supposed to work on this issue #851. Zone.js isn't in my stack because i'm using fetch from domain-task.

This is the error

Call to Node module failed with error: FetchError: request to https://localhost:44346/api/contracts failed, reason: unable to verify the first certificate
    at ClientRequest.<anonymous> (C:\Users\...\ClientApp\dist\vendor.js:44324:11)
    at emitOne (events.js:96:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.socketErrorListener (_http_client.js:309:9)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at emitErrorNT (net.js:1277:8)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9)

This is my controller

[Route( "api/[controller]" )]
[Authorize]
public class ContractController : Controller
{
	private readonly ApplicationDbContext context;

	public ContractController( ApplicationDbContext context )
	{
		this.context = context;
	}

	[HttpGet( "/api/contracts" )]
	public object GetContracts()
	{
		var contracts = context.Contracts.ToList();

		return new
		{
			Contracts = contracts
		};
	}
}

This is the js calling it

import { fetch, addTask } from "domain-task"

export const FETCH_CONTRACTS = "ContractActions/FetchContracts"

export const fetchContracts = () => dispatch => {
	let fetchTask = fetch("/api/contracts", {
		method: "GET",
		credentials: "same-origin",
		headers: {
			"Content-Type": "application/json"
		}
	}).then(response => response.json()).then(data => {
		dispatch({
			type: FETCH_CONTRACTS,
			contracts: data.contracts
		});
	});

	addTask(fetchTask);
	dispatch({ type: FETCH_CONTRACTS });
}

[SteveSandersonMS]

I guess you're using a self-signed cert (e.g., an IISExpress development cert), rather than a real HTTPS certificate. In that case, Node won't accept it by default, because Node doesn't use the system-configured list of trusted CAs - it uses a hard-coded built-in list of CAs instead (which has been reported as a bug to Node many times, but remains the case).

To fix this, you can either:

• Use a package such as ssl-root-cas to configure Node to trust your self-signed cert. I had a quick go at doing this, and couldn't get it to accept my IISExpress cert, so I'm not sure exactly what the process is. If you find out how to make this work, please let us know! However, even if you do make this work, it will still be inconvenient, because if you have more than one developer on your team using their own self-signed cert, they will each have to take steps to export that cert into some location where it can be read at runtime.
• Or, much more easily, disable HTTPS cert validation just for the requests where you know you are calling your own API from your backend (because in that case, the request isn't even going to leave the machine, so it's not really relevant to protect against MitM attacks). This is fairly simple to do. Add a function like the following to the file where you're making a fetch call (e.g., in WeatherForecast.ts):

function createRequestOptions(skipHttpsValidation: boolean): RequestInit {
    const isNode = typeof window === 'undefined';
    if (isNode) {
        var Agent = (require('https') as any).Agent;
        return {
            agent: new Agent({ rejectUnauthorized: !skipHttpsValidation })
        } as RequestInit;
    }
}

... and then change your fetch call from fetch('someurl') to fetch('someurl', createRequestOptions(true)) if you want to bypass HTTPS cert validation on that specific request. Don't do this for requests to external servers where you want to retain HTTPS cert validation.

I know it would be better if Node just used the system-configured CAs, but I'm not aware of a way to make it do that. If anyone does know a cross-platform way, please let us know!

[SteveSandersonMS]

BTW I know it's poor that this doesn't just work out of the box. Filed #1090 to track this, though it's possible that we can't do anything about it.

[JoshClose]

I'm getting an error when trying to use the Agent workaround.

Call to Node module failed with error: FetchError: invalid json response body at https://localhost:44346/Account/Login?ReturnUrl=%2Fapi%2Fcontracts reason: Unexpected token < in JSON at position 0
    at C:\Users\...\ClientApp\dist\vendor.js:14521:31
    at process._tickDomainCallback (internal/process/next_tick.js:135:7)

The server call has [Authorize] on it. If I take that off, it works. It looks like it's pulling the login page which makes sense if you're not authorized, which I am at this point. Normally I just have credentials: "same-origin" as an option in my fetch request and auth just works. It doesn't seem to when using the agent though.

Any idea how to get auth to work when using agent?

[JoshClose]

I was able to fix this by setting global.cookie = params.data.cookie; in my server.js file. The cookie is Cookie = (string)Context.Request.Headers["Cookie"] from the cshtml file. In my create fetch options method I then set the Cookie header along with the rejectUnauthorized setting.

Is there a better way to do this?

[SteveSandersonMS]

In general, you are on the right lines: if you want requests issued during server-side prerendering to have the same auth cookies as the request incoming to ASP.NET, then you need to pass that cookie data through to your JS boot code using asp-prerender-data, receive it in JS via params.data, and then ultimately set that on the outbound requests.

global.cookie = params.data.cookie;

I'm not familiar with the global.cookie API. I searched and couldn't find any references to what that is or where it's used. If it really is a "global" cookie store (as in, it will get used on all requests), then that's pretty alarming because you might be using the auth cookie from one user when prerendering for a different user. What you're doing might be fine, but I'd at least check that there's no way you're leaking cookie data from one user to another like this.

[JoshClose]

global meaning node's global scope. I have a method createFetchOptions that will check if it's running under node. If so, it'll use the agent stuff to set rejectUnauthorized, and it'll also set the cookie header with global.cookie. It's like the browsers window. cookie is just the property I'm creating for it. ;)

[JoshClose]

For reference, here is the method I'm using.

export function createFetchOptions(options = {}) {
	const isNode = typeof (window) === "undefined";
	const nodeOptions = !isNode ? {} : {
		agent: new (require("https").Agent)({
			rejectUnauthorized: false
		}),
		headers: {
			"Content-Type": "application/json",
			"Cookie": global.cookie
		}
	};

	const fetchOptions = {
		method: "GET",
		credentials: "same-origin",
		headers: {
			"Content-Type": "application/json"
		},
		...nodeOptions,
		...options
	};

	return fetchOptions;
}

[SteveSandersonMS]

it'll also set the cookie header with global.cookie. It's like the browsers window. cookie is just the property I'm creating for it

That sounds very dangerous. It sounds like you might be inadvertently sharing auth cookie values across different users. Anything you set on global is going to be reachable by code serving unrelated requests - it's like assigning to a static in C#.

[JoshClose]

That's not good. I figured each web request would have it's own instance of node that's running. Does the node instance running share it's data/context/global/whatever between aspnet web requests then?

[SteveSandersonMS]

I figured each web request would have it's own instance of node that's running

That would be really bad for performance :) Starting up a new Node instance takes at least a second or two. You can't really do that on every request. So we retain the same Node instance and use it to handle invocations across all requests. We only restart it if it crashes or has to be restarted because some code changed.

Does the node instance running share it's data/context/global/whatever between aspnet web requests then?

It's the same as any other Node runtime (because it is a real Node runtime).

[JoshClose]

Thanks. I'll look into another way of doing this.

[JoshClose]

How I fixed this issue is to put a cookie property on my initial redux state. Then on a fetch if it's a node request, it'll use the redux store state cookie.

For cookies in react components, I used react-cookie. This makes cookies available in components for server or client.