Auth attempts result in "unable to get local issuer certificate" error

[TimothyMBaB]

sfcc-ci Version

2.110

NodeJS Version

12.22.12

sfcc-ci Path

No response

Host OS Details

Microsoft Windows 10 Pro
10.0.19044 N/A Build 19044

What happened?

Attempts to connect to my sandbox for certain tasks fails to authorize. The connection for uploading code and using debugger works just fine, but tasks that try to zip upload (e.g. via OCAPI) all fail client auth.
I've included a full client:auth -D in the log output section, but the failure of the relevant task has a slightly different stack trace which may be of note:

$ npm run deploydata

> sfra_sfcc@6.3.0 deploydata C:\Users\TimothyM\ondemand10\build-a-bear-sfcc
> node tasks/deployTasks.js data

- Zipping Sitedata
√ Sitedata Zip Created
- Authenticating
× Authentication Failed
Error: Error: unable to get local issuer certificate
    at Request._callback (C:\Users\TimothyM\ondemand10\build-a-bear-sfcc\node_modules\sfcc-ci\lib\auth.js:794:22)
    at self.callback (C:\Users\TimothyM\ondemand10\build-a-bear-sfcc\node_modules\request\request.js:185:22)
    at Request.emit (events.js:314:20)
    at Request.onRequestError (C:\Users\TimothyM\ondemand10\build-a-bear-sfcc\node_modules\request\request.js:877:8)
    at ClientRequest.emit (events.js:314:20)
    at TLSSocket.socketErrorListener (_http_client.js:427:9)
    at TLSSocket.emit (events.js:314:20)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)
- Cleaning Up Workspace
√ Cleaning Up Workspace
Check your Client ID & Secret for accuracy.

The last line seems to be default for any auth failure, as we're sure those are accurate (and set correctly inside Business Manager, too.) And moreover the failure seems to be occurring before even getting to that part.

I've listed my own versions, but a coworker is getting identical errors with sfcc-ci 2.6.0 and node 10.23, so it isn't that particular. There is another on that same version who does not have this problem, but they are on Mac so it not that useful for comparison.

We are all working remotely on different networks, but there is still significant security applied to all of us (including the aforementioned working Mac.) Said security blocking something like a port or IP has been suggested as a possible cause, but only for lack of other ideas. If anyone has positive knowledge how this could be at fault, please advise what we could whitelist or relax.

Relevant log output

$ sfcc-ci client:auth -D
[DEBUG] Configuration loaded from C:\Users\TimothyM\ondemand10\build-a-bear-sfcc/dw.json
[DEBUG] Using secret SFCC_OAUTH_USER_NAME from dw.json located at C:\Users\TimothyM\ondemand10\build-a-bear-sfcc
[DEBUG] Using secret SFCC_OAUTH_USER_PASSWORD from dw.json located at C:\Users\TimothyM\ondemand10\build-a-bear-sfcc
[DEBUG] Authorize via Oauth password grant
[DEBUG] Doing auth request, payload: {"grant_type":"password","username":"timothym@buildabear.com","password":"redacted"}
REQUEST {
  uri: 'https://account.demandware.com/dw/oauth2/access_token',
  strictSSL: true,
  json: true,
  auth: {
    user: 'redacted',
    pass: 'redacted'
  },
  form: {
    grant_type: 'password',
    username: 'timothym@buildabear.com',
    password: 'redacted'
  },
  callback: [Function],
  method: 'POST'
}
REQUEST make request https://account.demandware.com/dw/oauth2/access_token
{
  request: {
    debugId: 1,
    uri: 'https://account.demandware.com/dw/oauth2/access_token',
    method: 'POST',
    headers: {
      host: 'account.demandware.com',
      'content-type': 'application/x-www-form-urlencoded',
      authorization: 'Basic redacted=',
      accept: 'application/json',
      'content-length': 86
    },
    body: 'grant_type=password&username=timothym%40buildabear.com&password=redacted'
  }
}
Error: Authentication failed: Error: unable to get local issuer certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1502:34)
    at TLSSocket.emit (events.js:314:20)
    at TLSSocket._finishInit (_tls_wrap.js:937:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:711:12) {
  code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
}

[tobiaslohr]

Hi @TimothyMBaB, in case you are using command sfcc-ci client:auth and you are not passing any user credentials, a lookup of user credentials from a dw.json in the current working directory or from well-known env vars is done, see also the help text sfcc-ci client:auth --help

If user credentials are not provided, they are read from a dw.json file located in the
current working directory. You may use environment variables SFCC_OAUTH_USER_NAME and
SFCC_OAUTH_USER_PASSWORD to pass the user credentials alternatively.

You can validate if this is happening, by using the --debug flag and check the debug logs in the console.

Looking at your debug logs, this seems to be the case.

We have recently merged #499 which allows you to force the CLI not to read the user credentials from the dw.json. This change will be in the upcoming 2.12.0 release. Another option you have is to change the working directory so that the dw.json is not found any longer.