GithubHelp home page GithubHelp logo

ukoloff / win-ca Goto Github PK

View Code? Open in Web Editor NEW
99.0 11.0 40.0 1.7 MB

Get Windows System Root certificates

License: MIT License

Python 1.56% C++ 6.30% JavaScript 3.32% Batchfile 0.31% C 1.91% LiveScript 86.60%
x509 node-js root-certificates node-forge openssl electron root-certificate certificate-authority vscode-extension pem

win-ca's Introduction

win-ca

Build status NPM version Store Roots

Get Windows System Root certificates for Node.js.

Rationale

Unlike Ruby, Node.js on Windows allows HTTPS requests out-of-box. But it is implemented in a rather bizarre way:

Node uses a statically compiled, manually updated, hardcoded list of certificate authorities, rather than relying on the system's trust store... Read more

It's somewhat non-intuitive under any OS, but Windows differs from most of them by having its own trust store, fully incompatible with OpenSSL.

This package is intended to fetch Root CAs from Windows' store (Trusted Root Certification Authorities) and make them available to Node.js application with minimal efforts.

Advantages

  • No internet access is required at all
  • Windows store is updated automatically (in most modern environments)
  • Manually installed Root certificates are used
  • Enterprise trusted certificates (GPO etc.) are made available too

Usage

For 95% of users:

  1. Just say npm install --save win-ca
  2. Then call require('win-ca').
  3. That's it!

If you need more - proceed to API section below.

By the way, win-ca is safe to be used under other OSes (not M$ Windows). It does nothing there.

Electron

win-ca was adapted to run inside Electron applications with no additional configuration (asar supported).

See Minimal Electron application using win-ca for usage example.

VS Code extension

Special extension for VS Code was created to import win-ca in context of VS Code's Extension Host.

Since all VS Code extensions share the same process, root certificates imported by one of them are immediately available to others. This can allow VS Code extensions to connect to (properly configured) intranet sites from Windows machines.

API

Click to view...

First versions of win-ca opened Windows' Trusted Root Certificate Store, fetched certificates, deduplicated them and installed to https.globalAgent.options.ca, so they are automatically used for all requests with Node.js' https module.

But sometimes one needs to get these certificates to do something else. For that case, full featured API was devised. It is the only function with numerous parameters and operation modes, eg:

const ca = require('win-ca')

rootCAs = []
// Fetch all certificates in PEM format
ca({
  format: ca.der2.pem,
  ondata: crt => rootCAs.push(crt)
})

Entry points

win-ca offers three ways of importing:

  1. Regular require('win-ca')
  2. Fallback require('win-ca/fallback')
  3. Pure API require('win-ca/api')

They all export the same API, but differ in initialization:

  1. win-ca does fetch certificates from Root store, saves them to disk and makes them available to https module with no effort.

  2. win-ca/fallback does the same, but it never uses N-API for fetching certificates, so it should work in all versions of Node.js as well as inside Electron application.

  3. win-ca/api does nothing, just exports API, so you decide yourself what to do.

API Parameters

API function may be called with no parameters, but that makes little sense. One should pass it object with some fields, ie:

  • format defines representation of certificates to fetch. Available values are:

    Constant Value Meaning
    der2.der 0 DER-format (binary, Node's Buffer)
    der2.pem 1 PEM-format (text, Base64-encoded)
    der2.txt 2 PEM-format plus some laconic header
    der2.asn1 3 ASN.1-parsed certificate
    der2.x509 4 Certificate in node-forge format (RSA only!)

    Default value is der.

    See also der2 function below.

  • store - which Windows' store to use. Default is Root (ie Trusted Root Certification Authorities).

    Windows has a whole lot of Certificate stores (eg Root, CA, My, TrustedPublisher etc.) One can list certificates from any of them (knowing its name) or several stores at once (using array for store parameter).

    var list = []
    require('win-ca/api')({store: ['root', 'ca'], ondata: list})
  • unique whether certificates list should be deduplicated. Default is true (no duplicates returned).

    Use {unique: false} to see all certificates in store.

  • ondata - callback fired for each certificate found.

    Every certificate will be converted to format and passed as the first (the only) parameter.

    As a syntactic sugar, array can be passed instead of function, it will be populated with certificates.

  • onend - callback fired (with no parameters) at the end of retrieval

    Useful for asynchronous invocations, but works in any case.

  • fallback - boolean flag, indicating N-API shouldn't be used even if it is available.

    Default value depends on Node.js version (4, 5 and 7 {fallback: true}; modern versions {fallback: false}). It is also true if Electron is detected.

    Finally, if win-ca has been required as win-ca/fallback, default value for this flag is also set to true.

    Note, that one can force N-API by setting {fallback: false}, but if Node.js cannot proceed, exception will be thrown. It can be catched, but Node.js will nevertheless remain in unstable state, so beware.

  • async - boolean flag to make retrieval process asynchronous (false by default)

    If true, API call returns immediately, certificates will be fetched later and feed to ondata callback. Finally onend callback will be called.

  • generator - boolean flag to emulate ES6 generator (default: false)

    If called with this flag, ES6 iterator object is immediately returned (regular or asynchronous - according to async flag).

    const ca = require('win-ca/api')
    
    // Iterate
    for (let der of ca({generator: true})) {
      // Process(der)
    }
    
    // Or thus (Node.js v>=6)
    let list = [...ca({generator: true})]
    
    // Or even (Node.js v>=10)
    for await(let der of ca({generator: true, async: true})) {
      // await Process(der)
    }

    Note, that if callbacks are set along with generator flag, they will be also fired.

  • inject - how to install certificates (default: false, ie just fetch from store, do not install)

    If set to true, certificated fetched will be also added to https.globalAgent.options.ca (in PEM format, regardless of format parameter), so all subsequent calls to https client methods (https.request, https.get etc.) will silently use them instead of built-in ones.

    If set to '+', new experimental method is used instead: tls.createSecureContext() is patched and fetched certificates are used in addition to built-in ones (and not only for https, but for all secure connections).

    Injection mode can be later changed (or disabled) with .inject() helper function.

  • save - how to save certificates to disk (default: false, ie use no I/O at all)

    If set to string, or array of strings, they will be treated as list of candidate folders to save certificates to. First one that exists or can be (recursively) created will be used.

    If no valid folder path found, saving will be silently discarded.

    If {save: true} used, predefined list of folders will be tried:

    • pem folder inside win-ca module itself
    • .local/win-ca/pem folder inside user's profile

    Certificates will be stored into the folder in two formats:

    • Each certificate as separate text file with special file name (mimics behavour of OpenSSL's c_rehash utility) - suitable for SSL_CERT_DIR
    • All certificates in single roots.pem file - suitable for SSL_CERT_FILE

    If win-ca is required not via win-ca/api, it calls itself with {inject: true, save: true} and additionaly sets ca.path field and SSL_CERT_DIR environment variable to the folder with certificates saved.

  • onsave - callback called at the end of saving (if save is truthy).

    Path to a folder is passed to callback, or no parameters (undefined) if it has been impossible to save certificates to disk.

Helper functions

Some internal functions are exposed:

der2

var certificate = ca.der2(format, certificate_in_der_format)

Converts certificate from DER to format specified in first parameter.

Function .der2() is curried:

var toPEM = ca.der2(ca.der2.pem)

var pem = toPEM(der)

hash

var hash = ca.hash(version, certificate_in_der_format)

Gives certificate hash (aka X509_NAME_hash), ie 8-character hexadecimal string, derived from certificate subject.

If version (first parameter) is 0, an old algorithm is used (aka X509_NAME_hash_old, used in OpenSSL v0.*), else - the new one (X509_NAME_hash of OpenSSL v1.*).

Function .hash() is also curried:

var hasher = ca.hash()
console.log(hasher(der))

inject

ca.inject(mode)
// or:
ca.inject(mode, array_of_certificates)

Manages the way certificates are passed to other modules.

This function is internally called by API when {inject:} parameter used.

First argument (mode) is injection mode:

  • false: no injection, built-in certificates are used

  • true: put certificates to https.globalAgent.options.ca and use them instead of built-in ones for https module

  • '+': new experimental mode: tls.createSecureContext() is patched and certificates are used along with built-in ones. This mode should affect all secure connections, not just https module.

Second parameter (array_of_certificates) is list of certificates to inject. If it is omitted, previous list is used (only inject mode is changed).

For example, simplest way to test new injection mode is:

const ca = require('win-ca') // Fetch certificates and start injecting (old way)

ca.inject('+') // Switch to new injection mode

Note, that this function should be called before first secure connection is established, since every secure connection populates different caches, that are extremely hard to invalidate. Changing injection mode in the middle of secure communication can lead to unpredictable results.

exe

Applications that use win-ca are sometimes packed / bundled. In this case one should find appropriate place for binary utility roots.exe (used in fallback mode, which is always the case with Electron apps) and then make win-ca to find the binary.

Function .exe() is intended to provide this functionality. You must call it before first invocation of library itself, eg:

var ca = require('win-ca/api')

ca.exe('/full/path/to/roots.exe')
ca({fallback: true, inject: true})

.exe() with no parameters switches to default location (inside lib folder). In any case it returns previous path to roots.exe:

console.log(require('win-ca').exe()) // Where is my root.exe?

Legacy API

Click to view...

win-ca v2 had another API, which is preserved for compatibility, but discouraged to use. It consists of three functions:

  • Synchronous:
    • .all()
    • .each()
  • Asynchronous:
    • .each.async()
var ca = require('win-ca')

do.something.with(ca.all(ca.der2.pem))

Note:

  1. All three yield certificates in node-forge's format by default (unlike modern API, that returns DER if unspecified by user).

    Unfortunately, node-forge at the time of writing is unable to parse non-RSA certificates (namely, ECC certificates becoming more popular). If your Trusted Root Certification Authorities store contains modern certificates, legacy API calls will throw exception. To tackle the problem - pass them format as the first parameter.

  2. .all() deduplicates certificates (like regular API), while both .each calls may return duplicates ({unique: false} applied)

  3. Root store always used (no way for store: option)

  4. Both .each calls require callback (with optional format)

    Synchronous .each() callback gets single argument - certificate (in specified format)

      var ca = require('win-ca')
      ca.each(ca.der2.x509, crt=>
        console.log(crt.serialNumber)
      )

    Asynchronous .each.async() callback gets two parameters:

    • error (which is always undefined in this version)
    • result - certificate in requested format or undefined to signal end of retrieval
    let ca = require('win-ca')
    
    ca.each.async((error, crt)=> {
      if (error) throw error;
      if(crt)
        console.log(forge.pki.certificateToPem(crt))
      else
        console.log("That's all folks!")
    })

N-API

Current version uses N-API, so it can be used in Node.js versions with N-API support, i.e. v6 and all versions starting from v8.

Thanks to N-API, it is possible to precompile Windows DLL and save it to package, so no compilation is needed at installation time.

For other Node.js versions (v4, 5 or 7) special fallback utility is called in the background to fetch the list anyway.

If you wish to use this fallback engine (even for modern Node.js), you can

require('win-ca/fallback')

Caveats

Windows 10 tends to have only a few certificates in its Trusted Root Certification Authorities store and lazily add them to it on first use.

If your OS does so, win-ca will still help to connect to your own sites (protected by self-signed certificates, or by the ones, distributed with GPO), but will make connection to well-known sites (like Google or Twitter) impossible!

The simplest remedy is to once open desired site in Internet Explorer / Google Chrome (certificate will be silently added to Root store).

Another option is to switch to new experimental injection method:

require('win-ca').inject('+')

Clear pem folder on publish

If you use win-ca in some Electron app or VS Code extension, be warned that node_modules/win-ca/pem folder is highly likely to be packed into your bundle with all root certificates on development machine.

You had better remove said folder before publishing (eg. in prepack npm script if it applies).

Building

  • npm install
  • npm run pretest
  • npm run nvm$
  • npm publish

This builds both x86 and x64 versions with N-API support. For older Node.js versions standalone binary utility is built.

See also

Credits

Uses node-forge and used to use node-ffi-napi (ancestor of node-ffi).

win-ca's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

win-ca's Issues

Support help needed for Dart port

I am working on a Dart port of this library, I have a few questions below, if you can spare a few minutes, it would be much appreciated:

win-ca/fallback does the same, but it never uses N-API for fetching certificates, so it should work in all versions of Node.js as well as inside Electron application.

Sounds like win-ca uses crypt32.dll while win-ca/fallback doesn't. How does win-ca/fallback get access to the cert list? https://github.com/ukoloff/win-ca/blob/master/fallback/index.js look empty

How can i solve this problem?Thanks

First of all,thanks for making such amazing tool.But when i have installed win-ca,my project couldn't run successfully.Could you please tell me what with it?Thanks very much!
./node_modules/win-ca/lib/index.js 5:2
Module parse failed: 'return' outside of function (5:2)
You may need an appropriate loader to handle this file type.
|
| if (process.platform !== 'win32') {
> return;
| }
|

Intellij extension

Hi! First of all thanks for your fantastic work. I was trying to reproduce the win-ca behavior under Intellij too. With VSCODE works like a charm.

Could it be possible to take advantage of this implementation under a plugin in intellij Idea?

local certs distributed with release app

I noticed when npm run postinstall is run, a copy of my local certs are copied to node_modules/win-ca/pem. Which are then distributed with the released app.

Not a huge deal, just wondering if that is intentional or something that could be turned off.

How to identify certificates

How can I identify the certificate that I intend to use?

I have all of the certificates that are installed on my machine. What's the correct way to filter out the one that I need from the list?

var crt, i, len, ref = ca.all();

for (i = 0, len = ref.length; i < len; i++){
    crt = ref[i];
    console.log("cert index " + i + " cert serial number" + crt.serialNumber + " subject " + crt.subject.attributes[0].value);
}

I tried to use serialNumber and subject. Serial Number (e.g. 355d700b594f0f8548854398397ad5d9) doesn't match what I see in the mmc.exe console under Certificates (e.g. ‎50 4f 34 9c 00 01 99 02 54 a9).

Subject can be duplicated so I hesitate to use that.

Extension breaks VSCode https connections when installed on MacOS

I have settings sync turned on, so this extension got enabled on my Mac as well. As a result, any extension that makes an https:// request just doesn't work with errors such as Unable to get local issuer certificate, etc. Is there a way to only run it on Windows?

How does it work with https.createServer

I'm trying to have an express app running on windows server.

I'm used to run it on linux and there it is easy:
const httpsOptions = {
key: fs.readFileSync('./key.pem'),
cert: fs.readFileSync('./cert.pem')
}

Do I just need to do it like this?

https.createServer(ca.all(), app).listen(443, () => {
console.log('server running at ' + 443);
})

Ignoring "save" parameter path

I'm using win-ca in an elecron app, but in a forked process, so "is-electron" returns false.

This is my implementation:

require('win-ca')({save: (process.env.USERPROFILE || process.env.HOME) + '\\.local\\win-ca\\pem'});

Everything works wonderfully in development, but when I build a release, it fails.

C:\Users\adam\.local\win-ca\pem\roots.pem is created, but it's 0 bytes and the forked process crashes with this error:

Error: EPERM: operation not permitted, open 'C:\\Program Files\\app\resources\\app.asar.unpacked\\node_modules\\win-ca\\pem\\roots.pem'
Emitted 'error' event at:
    at lazyFs.open (internal/fs/streams.js:273:12)
    at FSReqWrap.oncomplete (fs.js:141:20)

Why is it attempting to use the asar path when I have set the "save" path to a different path? Does it need to be set somewhere else as well?

Thank you!

Open Certificate import wizard ?

Can this library open the Certificate import wizard on windows or mac ?.

I'm currently working on a small application that do digital signing with pfx and other type of key store in client local Certificate. I intend to use nodejs as native application at client side to get and import their cert. Everything when great except the import certs part.

I can easily do this with c#, does this library support that ? I didn't see any api that allow me to do so.
I'm sorry if this not an issue.

Permissions Required To Work

What permissions are required to use this package to help configure LDAPS in express-ntlm?

I have a site that works as long as the Application Pool runs under a Local Administrator on that machine. I'd like to limit the service account's permission that the Application Pool runs under for better security. I have granted

  1. Grant read/execute to nodejs folder
    icacls "C:\program files\nodejs" /grant domain\svc_account:(OI)(CI)rx
  2. Grant read/execute to iinode folder
    icacls "C:\program files\iisnode" /grant domain\svc_account:(OI)(CI)rx
  3. Grant Full Control to the website folder
    icacls "D:\Websites\is-logging-api" /grant domain\svc_account:(OI)(CI)F
  4. Full Control to the private key used by the certificate (Open Certificates -> Right Click on yours -> All Tasks -> Manage Private Keys)

Please let me know if you need additional information.

Ability to specify file path for saving the root certificate files

My user case:

My NodeJS scripts and node_modules folder is deployed to "Program Files\MyApp" folder and ran as a window service. When the tool tries to write the root certificate to the node_modules it fails as it has no write permission to do so.

According to the windows guidelines, applications shall not require write permissions to their folder. It will be better if the application writing data to a user profile folder (C:\Users\username\AppData) or to a common data folder (C:\ProgramData).

I wonder if it is OK to add the ability for specifying the path for the root certificates so we can put them somewhere else.

Thanks for making this amazing tool!

Initializing crypt32-{arch}.node fails in vscode extensions when run in vscode Insiders 1.31.0

See microsoft/vscode-docker#733.

I assume this is related #8, but I don't fully understand the issues involved. vscode runs in Electron, but extensions run in a separate process, so I assume Electron has no effect on them. VS Code Insiders 1.31 has switched from Node 8.9.3 to 10.2.0, and process.versions.nApi is set to "3" there. If I force each.fallback to load, I don't have any problems.

Any ideas on what's going on here? Is it somehow a vscode issue? Thanks!

process.versions on VS Code 1.30.2:
image

process.versions on VS Code Insiders 1.31.0:
image

win-ca dependent library has security vulnerability

The node-forge-0.10.0.tgz has a security vulnerability.

CVE-2022-0122
JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.

The latest available version of node-forge is 1.2.1.

Please upgrade the version of node-forge and release an updated version of win-ca.

support reading from other stores

Can you add support for reading certificates from multiples stores?

I used to use a fork I did for your library where I implemented like this:
jfromaniello@f5a9fcd#diff-9395dacd601c601e42e789fd2f69a6a6

but I see this is now implemented in c and I am not familiar with it.

I'd like to add certificates from TRUSTEDPEOPLE and CA in addition to ROOT. Example:

winCa.each(['TRUSTEDPEOPLE', 'CA', 'ROOT'], function(ca){
//    if (moment(ca.validity.notAfter).isBefore()) { return; }
    cas.push( { pem: forge.pki.certificateToPem(ca) });
});

Thanks a lot!

"Error: Self signed certificate in certificate chain" in win 10

I am receiving a "self signed certificate in certificate chain" in a fresh windows 10 installation with default certificates. Working correctly in win 8.1.
self signed certificate in certificate chain at TLSSocket. (_tls_wrap.js:1103:38) at emitNone (events.js:105:13) at TLSSocket.emit (events.js:207:7) at TLSSocket._finishInit (_tls_wrap.js:637:8) at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:467:38)

Any clues?

Issues with VSCode Extension

Hello,

First of all, thank you for maintaining this solution on so many platforms. I was very annoyed when I read about using it as a workaround for the Home Assistant Config Helper, but as you know better than I do, that is simply a Windows problem...

Anyway, I am having trouble getting my installation of the Home Assistant Config Helper VSCode extension to connect to my Home Assistant server via HTTPS. I have generated my own certificates, and I installed the Certificate Authority's public certificate into both the Windows certificate store (as a User under Trusted Root Certificate Authorities) and into my browsers (Firefox manually, Chrome automatically via Windows certificates).

The browsers work fine, but the Home Assistant extension in VSCode seems to be having trouble:

[Home Assistant Language Server(10460)] Started and initialize received
Connecting to Home Assistant...
[Auth phase] Initializing WebSocket connection to Home Assistant
[Auth Phase] Connecting to Home Assistant... Tries left: 3
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: unable to verify the first certificate
Applying schemas to 6 of your configuration files...
Schemas updated!
[Auth Phase] Connecting to Home Assistant... Tries left: 2
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: unable to verify the first certificate
[Auth Phase] Connecting to Home Assistant... Tries left: 1
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: unable to verify the first certificate
[Auth Phase] Connecting to Home Assistant... Tries left: 0
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: unable to verify the first certificate

When I enable the vscode-home-assistant.ignoreCertificates setting (which I do not think I should have to do, and defeats the purpose of trying to use win-ca), the connection succeeds:

Connecting to Home Assistant...
[Auth phase] Initializing WebSocket connection to Home Assistant
[Auth Phase] Connecting to Home Assistant... Tries left: 3
[Auth phase] Received a message of type auth_required
[Auth phase] Received a message of type auth_ok
Connected to Home Assistant

After a bit of research, I tried changing my Home Assistant server's certificate to include the Certificate Authority's public certificate as well as its own public certificate (in a combined file). This still works in my browsers, but produces a different error with the Home Assistant Config Helper:

Connecting to Home Assistant...
[Auth phase] Initializing WebSocket connection to Home Assistant
[Auth Phase] Connecting to Home Assistant... Tries left: 3
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: self signed certificate in certificate chain
[Auth Phase] Connecting to Home Assistant... Tries left: 2
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: self signed certificate in certificate chain
[Auth Phase] Connecting to Home Assistant... Tries left: 1
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: self signed certificate in certificate chain
[Auth Phase] Connecting to Home Assistant... Tries left: 0
WebSocket Connection to Home Assistant closed with an error: Disconnected from Home Assistant with a WebSocket error with message: self signed certificate in certificate chain

I am not 100% sure if this is a problem with win-ca, Home Assistant Config Helper, or some misunderstanding I have with how Windows is trying to validate SSL certificates... but I expected win-ca to make the certificate available and it does not seem able to do so. Do you have any thoughts or experiments I could try?

Thank you!

Wrapper for npm

I just stumbled on this package, and I think it really fills a gap for corporate users where the certificate setup for Node.js is a struggle for many users.

However, in our environment, the npm repositories are not excluded from DPI. This means that on a fresh machine with Node.js installed, npm install doesn't work due to certificate validation issues. I can work around that, but this still leaves the general user with the same struggle as before, unless they get a prebundled software where this package is already included.

I got the idea that maybe this package can be used like a wrapper (or fork) of npm binary - hence solving the npm issue too. Has this been considered?

can this library be used in browser context?

i am trying to see if pulling the certificates is possible when bundled up wit angular/typescript from a browser, then it can fetch certs from the user device certificate store.

Running a test on github actions windows server crashes root.exe with ENOBUFS

Context is this pr: usethesource/rascal-language-servers#229

     Error: spawnSync D:\a\rascal-language-servers\rascal-language-servers\rascal-vscode-extension\node_modules\win-ca\lib\roots.exe ENOBUFS
      at Object.spawnSync (node:internal/child_process:1119:20)
      at spawnSync (node:child_process:847:24)
      at Object.execFileSync (node:child_process:890:15)
      at Object.run (node_modules\win-ca\lib\fallback.js:43:26)
      at api (node_modules\win-ca\lib\index.js:60:10)
      at fetch (out\auto-jvm\downloaders.js:93:13)
      at Object.identifyLatestTemurinLTSRelease (out\auto-jvm\downloaders.js:172:31)
      at Context.<anonymous> (out\test\normal-suite\JavaDownload.test.js:39:85)
      at processImmediate (node:internal/timers:466:21)

It looks like the roots.exe lib fails to be executed. The same test runs on my local windows machine.

I would like to help debug this, but I do not know where to start.

Pull from "Computer Certificates" instead of "User Certificates"

I read through the API documentation, but could not find an explicit mention of this. I am looking for a way to specify that the certificates should be pulled from the Local Computer's certificates instead of the Current User's certificates (see snapshot).

image

Allow roots.exe's path to be configurable

The path to roots.exe is currently set as a constant: https://github.com/ukoloff/win-ca/blob/master/src/fallback.ls#L5

In less vanilla packaging scenarios, it's useful to let the user configure where this executable will be. Like when using pkg. This path could be passed to the initialization function. E.g.

var ca = require('win-ca/api');
ca({fallback: true, inject: true, roots: path.join(...)});

See also this note on node-regedit for an example of this feature.

Issue with expired certs on Windows

win-ca seems to read the expired certs from Windows which causes websocket requests to error out with certificate expired error. This issue can be reproduced if you have both the Let's Encrypt DST Root CA X3 certificate and the newer ISRG Root X1 certificate and you try opening a websocket connection using Node's websocket package.
Here's a snippet of the error:
request to https://xyz/abc failed, reason: certificate has expired".

[HELP] problem "nssm" when I use "win-ca"

Hello,

I have a problem with nssm when I use win-ca. Could you help-me?

First Test (running project with nssm):

  1. Installer:
    2022-08-16_09h06_27

  2. Service Running:
    2022-08-16_09h06_57

  3. Login OK:
    2022-08-16_09h07_22

  4. But, when I call on my backend win-ca not running:
    2022-08-16_09h07_32

Second Test (running project without nssm):

  1. My Project:
    2022-08-16_09h08_07

  2. Open console and call exe without using nssm:
    2022-08-16_09h08_15

  3. Project running:
    2022-08-16_09h08_27

  4. Login OK:
    2022-08-16_09h08_46

  5. win-ca working without nssm:
    2022-08-16_09h08_56

Sorry about my English, I'm a Brazilian.

Thanks for your help.

Usage with workers

Regardless of injection method, using win-ca within (multiple concurrent) NodeJS workers results in the following error.

FATAL ERROR: HandleScope::HandleScope Entering the V8 API without proper locking in place

Presumably this has something to do with shared state between the worker process and the parent, but I really have no clue what's going on here. Is there any way to get win-ca to work properly for code running within a worker?

Electron - Packaged : Cannot read property 'stdout' of undefined

Hi @ukoloff !

I have an issue with Electron. When I packaged the application and launch it, I have this error :
image

Cannot read property 'stdout' of undefined

I just import it on the main thread with :
import 'win-ca';

I use :
Electron : 4.0.2
Electron-builder : 20.43.0
win-ca : 3.1.0

Can you help me with that ?
If you want any other information, tell me !

Unreadable codes in Chinese when use win-ca

Hi,
I use win-ca in my nodejs project to get certificate, and here is my code:

export function getAllCerts() {
  return new Promise(resolve => {
    ca({
      async: true,
      format: ca.der2.txt,
      ondata: roots,
      onend: resolve
    })
  }).then(() => {
    console.log(roots)
    return roots
  })

And it works well in English format, but when the certificate content contains Chinese, I got unreadable codes. I think the reason is the encoding format in win-ca,and I want to know how to resolve this problem.

THX very much!

Syntax Error in README example

It looks like the following code in the README example is

for crt in ca.all()
  dst.write forge.pki.certificateToPem crt

should read

for (crt in ca.all())
  dst.write forge.pki.certificateToPem crt

It causes a syntax error without the () around the inner part crt in ca.all().

When I run it, I get the following error as well.

for (crt in ca.all())
               ^

TypeError: ca.all is not a function
    at Object. (C:\Users\user\Source\Repos\testingNTLM\app.js:8:16)
    at Module._compile (module.js:635:30)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Function.Module.runMain (module.js:676:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:608:3

Is there something that I'm missing?

npm install - node 10.6

Hi , can't install the module - what would be the way to troubleshoot the errors?
It's on
Windows 10.0.14393
3020 verbose node v10.6.0
3021 verbose npm v6.1.0
Are Admin permissions required?

012 silly saveTree `-- [email protected]
3012 silly saveTree   +-- [email protected]
3012 silly saveTree   +-- [email protected]
3012 silly saveTree   | `-- [email protected]
3012 silly saveTree   +-- [email protected]
3012 silly saveTree   `-- [email protected]
3012 silly saveTree     `-- [email protected]
3013 warn [email protected] No description
3014 warn [email protected] No repository field.
3015 verbose stack Error: [email protected] postinstall: `node -e "try{require('.')}catch(e){}"`
3015 verbose stack Exit status 3221225477
3015 verbose stack     at EventEmitter.<anonymous> (D:\Program Files (x86)\npm\6.1.0\node_modules\npm\node_modules\npm-lifecycle\index.js:304:16)
3015 verbose stack     at EventEmitter.emit (events.js:182:13)
3015 verbose stack     at ChildProcess.<anonymous> (D:\Program Files (x86)\npm\6.1.0\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
3015 verbose stack     at ChildProcess.emit (events.js:182:13)
3015 verbose stack     at maybeClose (internal/child_process.js:961:16)
3015 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:5)
3016 verbose pkgid [email protected]
3017 verbose cwd D:\home\site\wwwroot
3018 verbose Windows_NT 10.0.14393
3019 verbose argv "D:\\Program Files (x86)\\nodejs\\10.6.0\\node.exe" "D:\\Program Files (x86)\\npm\\6.1.0\\node_modules\\npm\\bin\\npm-cli.js" "install"
3020 verbose node v10.6.0
3021 verbose npm  v6.1.0
3022 error code ELIFECYCLE
3023 error errno 3221225477
3024 error [email protected] postinstall: `node -e "try{require('.')}catch(e){}"`
3024 error Exit status 3221225477
3025 error Failed at the [email protected] postinstall script.
3025 error This is probably not a problem with npm. There is likely additional logging output above.
3026 verbose exit [ 3221225477, true ]

Rebuild for Electron 3.0.x

Win-Ca 2.1.0 will not start up with Electron 3.x

With Electron version 3.x initializing crypt32-{arch}.node will fail. Rebuilding with Electron-Rebuild fixes this. Please release a new version of win-ca which is compatible with Electron 3.x.

"Saved [date] by win-ca" in every certificate can break building process

Hello,

when win-ca is used in environment where bundle/asar/any other build result files are checked by checksum, a comment in every PEM mentioning save date affects the hash.

Imagine situation: The same code being built twice in CI. Since CI does builds from scratch, it starts by modules installation and therefor every build gets different certificate files. The difference is of course in the saved date.

Subject	US/Washington/Redmond/Microsoft Corporation/Microsoft ECC TS Root Certificate Authority 2018
Valid	180227205134Z - 430227210012Z
Saved	2020-04-03 16:37:58 GMT+0000 by [email protected]
-----BEGIN CERTIFICATE-----

This breaks the checksum of the files and other mechanisms following.

We managed by adjusting the files our own way. This is just to consider whether the comment is really necessary.

Greetings.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.