Rocket.chat: Allow invalid and Self-Signed SSL not effective for oauth

[Shelnutt2]

I'm testing rocket.cat with gitlab oath. I've got a self signed cert on the gitlab server, and I'm unable to authenticate against it due to the self signed certificate.

{"line":"398","file":"oauth_server.js","message":"Error in OAuth Server: Failed to complete OAuth handshake with gitlab at https://example.com/oauth/token. DEPTH_ZERO_SELF_SIGNED_CERT","time":{"$date":1443438610410},"level":"warn"}

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Shelnutt2]

I've tracked this down to to meteor's oath package. I don't think this can be solved easily with the existing configuration option.

I've worked around it by adding NODE_TLS_REJECT_UNAUTHORIZED=0 as en environmental variable to the docker-compose.yml

[dalenoe]

I am also having this problem. Where can I add that environmental variable on a regular install?

[dalenoe]

This is what I am seeing in the error log.

UNABLE_TO_VERIFY_LEAF_SIGNATURE

[pa-de-solminihac]

I am facing the same problem.

I have solved a similar issue when testing gitlab's embedded mattermost with gitlab as OAuth.

My (legitimate) certificate' authority (RapidSSL) was not in their _embedded_ cacert.pem file. I did not find a proper way of fixing this so I changed gitlab's cacert.pem file with this ugly trick:

# fix gitlab cacert missing rapidssl
echo -e "\nRapidSSLCA-G3\n=============" >> /opt/gitlab/embedded/ssl/certs/cacert.pem && \
cat /etc/ssl/certs/RapidSSLCA-G3.pem >> /opt/gitlab/embedded/ssl/certs/cacert.pem

Using the docker vesion of Rocket.Chat. Is there a way of achieving the same fix (or even a less ugly one) ?

EDIT: @Shelnutt2 's solution is less ugly and works great too :

adding NODE_TLS_REJECT_UNAUTHORIZED=0 as en environmental variable to the docker-compose.yml

[umdstu]

I'm having a related issue with an internal version of gitlab. Trying to oauth against gitlab yields the error SELF_SIGNED_CERT_IN_CHAIN, rather than the one (DEPTH_ZERO_SELF_SIGNED_CERT) listed above. Perhaps its related?

[lkebin]

I'm having a similar issue with LDAP settings (Using Rocket.Chat with docker). My LDAP server(openLDAP) using SSLMate wildcard certificate.

But when I install Rocket.Chat manually on local server, it is working. Using same LDAP server and configurations.

[engelgabriel]

Have you tried setting the NODE_TLS_REJECT_UNAUTHORIZED to false on the admin panel?

[ScOut3R]

I am also facing a self signed certificate issue when trying to authenticate through a CAS server. I am running 0.45 with the official Docker image. I've supplied NODE_TLS_REJECT_UNAUTHORIZED=0 to the Docker container and I've enabled _Allow Invalid Self-Signed Certs_ in _General_ settings. Still when the authentication happens I get the following error from Rocket.Chat:

rocketchat_cas rocketchat_cas.js:155 CAS ➔ error error when trying to validate: self signed certificate in certificate chain.

Am I missing something obvious?

UPDATE: I've traced this back all the way to https://github.com/kcbanner/node-cas/blob/master/lib/cas.js#L406. I assume the solution there completely ignores the value of NODE_TLS_REJECT_UNAUTHORIZED and that may be the issue.

[sergioloyola]

I have problems too. Since my CAS idp uses self-signed certificates, when I try to authenticate my idp indicates that it was successful, but rocket.chat shows me the following error:

_rocketchat_cas rocketchat_cas.js:169 CAS ➔ error error when trying to validate: unable to verify the first certificate_

Who had to deal with the same problem ???

[wcgcoder]

@ScOut3R Did you make any progress circumventing the new CAS limitations? I tried passing my root CA to the node-cas module with the ssl_ca option with no luck. This was done by changing the rocket chat cas_server.js and building from source. 😢

Unfortunately, I still had no luck!

[ScOut3R]

@wcgcoder Well, I worked around the issue by buying a trusted certificate for our Rocket.Chat instance.

[wcgcoder]

@ScOut3R Unfortunately, some organizations have internal certificate authorities they're mandated to use (by law).

In other environments, I'd just use let's encrypt to get my certs.

[moonwolf-github]

Any plans to solve this issue? I've just encountered it when testing nextcloud oauth.