Error: self signed certificate in certificate chain

[marcopalumbo]

Hi Everyone

when I try pluralith graph I get this error:

Error: self signed certificate in certificate chain at TLSSocket.onConnectSecure (node:_tls_wrap:1532:34) at TLSSocket.emit (node:events:527:28) at TLSSocket._finishInit (node:_tls_wrap:946:8) at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:727:12) { code: 'SELF_SIGNED_CERT_IN_CHAIN',

I guess it's due to the company firewall that does SSL inspection and so Pluralith stumble upon it

It would be nice to have a --ignore-ssl-errors option to skip SSL errors/verification in cases like mine

[DanThePutzer]

Hi @marcopalumbo

This is a very weird one. I'm trying to figure out where in the heck it is running into a self-signed certificate. There are ways to ignore SSL errors, but that compromises safety. Every request the Pluralith CLI makes should use SSL, so I'm not sure what is going on here.

Is there anything we are doing wrong that causes your firewall to complain? Or is this a problem on your end? A bit more context would be super helpful to get to the bottom of this!

[marcopalumbo]

Hi @DanThePutzer

Probably my explanation wasn't so understandable...

AFAIK the "pluralith graph" command interact with the pluralith api so to send the needed info to graphically reproduce the infrastructure and it calls on https://api.pluralith.com/v1/graph/get/current/ authenticating itself with the API Key as Bearer Token

The SSL inspection (any... not only ours) works like a MITM attack presenting to the client (Lan PC's) a "self-signed" SSL Cert with the same CN of the destination cert (api.pluralith.com) but issued by the Firewall CA that is trusted by the local domain and then the firewall itself communicate with the real endpoint api.pluralith.com This allows the firewall to see through all packets passing by, spotting out malicious code, encryption keys (used by ransomware) and a lot of other interesting analysis

So I'm 99% sure is nothing on your side, rather is this protection system that creates the issue, it happens also with wget commands and in that case the --no-check-certificate is used

I don't know how other company workaround this in the "pluralith scenario" but here the IT Security Dept. is (reasonably) not willing to have a proliferation of exclusions to the generic rule

Hope this shed some light on the matter

[marcopalumbo]

After some Wireshark analysis it sorted out that the call creating the issue wasnt to https://api.pluralith.com/v1/graph/get/current/ but to https://mil04s51-in-f19.1e100.net (corresponding to 142.241.209.51) After excluding it from SSL Decrypt everything worked like a charm

BTW the workaround applied is quite horrific... the fqdn indicated may change without notice

[SylvainMartel]

Still not working here. :(

[evandena]

Same issue here, corporate SSL inspection. Is there a way to provide an internal CA or use the systems SSL bundle? MacOS here.