opened
mhseiden
username_0
We are seeing the following error bubble up on occasion. It looks like it's coming from the `ocsp` library that y'all are using.

```
ERROR: [9:34:45.3445 AM]: OCSP validation failed: Error: Unsupported type: object at: (shallow)
```
OCSP is randomly failing in master
issue
created
smtakeda
username_1
hmm, sounds like garbage was returned from OCSP responder... The driver needs retry.

Currently NodeJS doesn't cache the OCSP response nor uses the OCSP cache server, OCSP check is not as stable as JDBC, ODBC, Python Connector.  We'll add it in the earliest opportunity.
For workaround, use `insecureConnect` parameter to skip OCSP check.
```
var connectionOptions =
{
  account: testaccount, ... , insecureConnect: true
}
```
Note `insecureConnect=true` will still do 1) verify the certificate signature, 2) check validity, 3) ensure the certificate is associated with the hostname.
comment
created
natesilva
username_2
Workaround: the `insecureConnect` option needs to be passed to `snowflake.configure(...)`, not to the `createConnection` function.

```
snowflake.configure({insecureConnect: true});
var connection = snowflake.createConnection(...);
```
comment
created
rem7
username_3
```  name: 'NetworkError',
  code: 401001,
  message: 'Network error. Could not reach Snowflake.',
  cause: Error: Bad OCSP response status: try_later
```
seeing the same issue
comment
created
moniecodes
username_4
Is there any update on this issue?  

What is the impact of using` insecureConnect:true`.  I assume we want the OCSP checks when using node client?
comment
created
NoxHarmonium
username_5
FWIW I was having the `OCSP validation failed: Error: Unsupported type: object at: (shallow)` error and it turned out to be the version of `asn1.js` that was getting resolved. I think that the version range isn't restrictive enough so if another library uses `asn1.js` but an incompatible version it can break this library. I fixed it by adding:

```
  "resolutions": {
    "asn1.js": "^5.4.1"
  },
```

To my package.json file (I use Yarn, the syntax might vary for NPM). I'm not sure if it is the same issue you are having but it might help.
comment
created
bajohn
username_6
Thank you! This worked for me, in Node I just set the following in package.json dependencies:
```
    "asn1": "^0.2.4",
```
, delete my package-lock.json / node_modules to make sure a lower version wasn't still being used, then rerun `npm install`. Snowflake is now connecting correctly.
comment
created
markandrus
username_7
@username_5 @username_6 thanks for pointing me in the right direction. I dove into snowflake-sdk's ocsp and asn1.js dependencies. It looks really messy:

* ocsp@1.2.0 depends on asn1.js-rfc5280@^2.0.0
* ocsp@1.2.0 depends on asn1.js-rfc2560@^4.0.0
* asn1.js-rfc2560@4.0.6 depends on asn1.js-rfc5280@^2.0.0
    * asn1.js-rfc5280@2.0.1 depends on asn1.js@^4.5.0
* snowflake-sdk@1.6.4 depends on asn1.js-rc2560@^5.0.0
* snowflake-sdk@1.6.4 depends on asn1.js-rfc5280@^3.0.0
* asn1.js-rfc2560@5.0.1 depends on asn1.js-rfc5280@^3.0.0
    * asn1.js-rfc5280@3.0.0 depends on asn1.js@^5.0.0
* snowflake-sdk@1.6.4 depends on ocsp@^1.2.0
    * ocsp@1.2.0 depends on asn1.js@^4.8.0

In a recent install, I ended up with

* asn1.js@4.10.1 and asn1.js@5.4.1
* asn1.js-rfc5280@2.0.1 and asn1.js-rfc5280@3.0.0
* asn1.js-rfc2560@4.0.6 and asn1.js-rfc2560@5.0.1

So I can definitely see how this can cause problems. I think the issue would best be solved in ocsp and asn1.js, releasing packages that update to the latest versions (assuming they're compatible). Then, I'd expect to just need

* asn1.js@5.4.1
* asn1.js-rfc5280@3.0.0
* asn1.js-rfc2560@5.0.1
comment
created
wpride
username_8
You're a legend, this worked beautifully
comment