In Angular and ReactRedux templates, the FetchData sample page fails if served over HTTPS with self-signed cert #608

Closed
opened 2025-08-09 17:16:57 +00:00 by fergalmoran · 0 comments
Owner

Originally created by @SteveSandersonMS on 7/5/2017

The underlying issue is that Node.js doesn't respect the OS-configured trusted CAs (details - and note it's still the case in Node 8.x, even though this issue was marked closed). This means it doesn't recognise self-signed certs such as an IISExpress development cert, even if you agreed to register it as trusted in the OS. Instead, Node expects you to use a technique like this to manually load your trusted certs from files on disk.

The consequence is that, during server-side prerendering, API requests to https://localhost... will fail if the cert isn't chained to one of Node's built-in CAs. Hence you will get an error if you try to do server-side prerendering on the "fetchdata" page in the Angular or ReactRedux templates.

Possible workarounds

  1. You can disable HTTPS validation at the entire Node process level using the code or env var process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";.
  2. You can disable HTTPS validation on a per-request basis by setting the option agent: new (https.Agent)({ rejectUnauthorized: false }) on the call to Node's native https API, if you can access that.
  3. Maybe - not tested - it might be possible to get Node to load the OS-trusted certs by some combination of the NPM packages trusted-ca (for Mac and some Linux distributions) plus node-windows-certs.

Workaround 3 would be best if it was robust, but it's hard to be sure of that, given that Linux distributions could put their CA cert store anywhere. It really feels like it should be a native feature in Node, not something hacked in at the application level.

Workaround 2 would be OK, since you'd only do it on requests that you know are going to your own backend server. However it's not really practical in the Angular case, because Angular apps are so deeply abstracted and there's no simple way of passing arbitrary options to Node's https API (reported as bug to request workaround). It would be OK in the ReactRedux case, but we don't want a solution that only works in one place.

Workaround 1 might be acceptable if we know your application was built in development mode. You wouldn't want this global flag set in production, hopefully.

*Originally created by @SteveSandersonMS on 7/5/2017* The underlying issue is that **Node.js doesn't respect the OS-configured trusted CAs** ([details](https://github.com/nodejs/node/issues/4175) - and note it's still the case in Node 8.x, even though this issue was marked closed). This means it doesn't recognise self-signed certs such as an IISExpress development cert, even if you agreed to register it as trusted in the OS. Instead, Node expects you to use [a technique like this to manually load your trusted certs from files on disk](https://www.npmjs.com/package/ssl-root-cas). The consequence is that, during server-side prerendering, API requests to `https://localhost...` will fail if the cert isn't chained to one of Node's built-in CAs. Hence you will get an error if you try to do server-side prerendering on the "fetchdata" page in the Angular or ReactRedux templates. ### Possible workarounds 1. You can disable HTTPS validation at the entire Node process level using the code or env var `process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";`. 2. You can disable HTTPS validation on a per-request basis by setting the option `agent: new (https.Agent)({ rejectUnauthorized: false })` on the call to Node's native `https` API, if you can access that. 3. Maybe - not tested - it might be possible to get Node to load the OS-trusted certs by some combination of the NPM packages [`trusted-ca`](https://www.npmjs.com/package/trusted-ca) (for Mac and some Linux distributions) plus [`node-windows-certs`](https://www.npmjs.com/package/node-windows-certs). Workaround 3 would be best if it was robust, but it's hard to be sure of that, given that Linux distributions could put their CA cert store anywhere. It really feels like it should be a native feature in Node, not something hacked in at the application level. Workaround 2 would be OK, since you'd only do it on requests that you know are going to your own backend server. However it's not really practical in the Angular case, because Angular apps are so deeply abstracted and there's no simple way of passing arbitrary options to Node's `https` API ([reported as bug to request workaround](https://github.com/angular/universal/issues/752)). It would be OK in the ReactRedux case, but we don't want a solution that only works in one place. Workaround 1 might be acceptable if we know your application was built in development mode. You wouldn't want this global flag set in production, hopefully.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/JavaScriptServices#608
No description provided.