I have GitLab Omnibus 8.0.x and Mattermost running on SSL with self-signed certificates.
On authentication I have this error in the Mattermost logfile:
Token request failed [details: Post https://some.domain.tld/oauth/token: x509: certificate signed by unknown authority
Does somebody know where or how I can tell Mattermost to trust the certificate?
Thanks a lot
Is your SSL termination for Gitlab happening at a proxy in front of the actual Gitlab rails service or is Gitlab doing the SSL termination itself? Is Mattermost by any chance running on the same host as your Gitlab instance?
No proxy. Gitlab and Mattermost running on the same host. Installation on Ubuntu 14.04 from GitLab CE Omnibus packages.
I have self-signed certificates for each subdomain git.domain.tld and mat.domain.tld. Maybe I should have created a wildcard cert?
Thanx!
Did you solve this problem? Got a similar problem with an untrusted CA here.
We are using a self-signed certs on our server. In order for the server to trust your own CA, you need to add the certs to the CA certificates store. This link describes most ways of the ways to do this on Linux systems. Basically, you need to add the cert to /usr/local/share/ca-certifcates and run update-ca-certifcates on Ubuntu systems.
Hope this helps.
Hi mattc,
worked pretty fine for my scenario. Since I’m running Apache2 ReverseProxies for gitlab and mattermost, I needed to add the following line in my configuration
SSLCACertificateFile /usr/local/share/ca-certificates/ORG-zcore-CA.crt
since i’m not using a self-signed certificate, but a untrusted CA for internal server.
Thank you @mattc !
Adding the .crt to /usr/local/share/ca-certifcates and run update-ca-certificates did the trick!!
I am using the gitlab-ce omnibus rpm with SSL certificates issued by an internal CA, and while my system is correctly configured (openssl verify is happy with the certs), I was still getting this error in /var/log/gitlab/mattermost/mattermost.log
[2016/01/05 18:01:07 SAST] [EROR] /login/gitlab/complete:AuthorizeOAuthUser code=500 rid=XXXXX uid= ip=192.168.0.64 Token request failed [details: Post https://gitlab.XXXXXXX/oauth/token: x509: certificate signed by unknown authority]
The omnibus package ships its own openssl libraries, with their own trusted certs in /opt/gitlab/embedded/ssl/certs/cacert.pem
In order to avoid this problem in future, I have symlinked the system CA cert bundle:
ln -s /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt /opt/gitlab/embedded/ssl/certs/cacert.pem
(On Red Hat-based systems, you should use update-ca-trust to update the CA cert bundle, see ‘man update-ca-trust’).
Depending on which distributions are supposedly supported with the omnibus RPMs, it might make more sense for it to configure the included openssl to use the OS-provided CA certificate store.
I had to also add both hostnames in the same line to /etc/hosts
127.0.0.1 localhost
191.168.1.x mattermost.naneya.com gitlab.naneya.com mattermost gitlab
After that the certs worked as well
Thanks! Saved me a lot of time!
Problem still the same on debian 7.10 wheezy with gitlab 8.6.6, even if i try the solution
ln -s /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt /opt/gitlab/embedded/ssl/certs/cacert.pem
same for this trick which does not work
Adding the .crt to /usr/local/share/ca-certifcates and run update-ca-certificates did the trick!!
I always have
[2016/04/20 19:15:39 EDT] [EROR] /signup/gitlab/complete:AuthorizeOAuthUser code=500 rid=XXX uid= ip=209.136.225.254 Token request failed [details: Post https://gitlab.marymorstan.com/oauth/token: x509: certificate signed by unknown authority]
with self signed certifcate, and with free certificate signed with startssl…
EDIT: I upgrade from wheezy to jessie and no problem anymore
EDIT: now i have another problem with incoming webhook which does not work anymore
Hook executed successfully but returned HTTP 500
{"id"=>"web.incoming_webhook.text.app_error", "message"=>"No text
specified", "detailed_error"=>"",
"request_id"=>"XXX", "status_code"=>500,
"is_oauth"=>false}
Note: Here the error I got through webhook on gitlab, If i setup through service slack, I just go a 500 error page
I have this same issue, but wanted to document how I solved this issue since this is one of the top google search results regarding the x509: certificate signed by unknown authority issue.
I read through all the other links / issues mentioned here and did run across a couple others
But ultimately, I would recommend reading the following blog post that describes why SSL certs are different on different systems and why this causes so much headache:
In my specific use case, we run a RHEL / Centos 6 server.
While I had already added my Internal CA root certificate to the /etc/pki/ca-trust/source/anchors/ directory and then ran the update-ca-trust as root. This updates certificates in the /etc/pki/ca-trust/extracted directory.
After updating this and forcing the GitLab CA certificate to point to this extracted certificate, I still could not get Mattermost to connect properly:
[root@server /]# ls -la /opt/gitlab/embedded/ssl/certs/
total 8
drwxr-xr-x. 2 root root 4096 Jul 21 13:19 .
drwxr-xr-x. 4 root root 4096 Jul 21 12:47 ..
lrwxrwxrwx. 1 root root 55 Jul 21 13:02 cacert.pem -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
It wasn’t until I saw that there was another certs directory from the HappyAssassin blog post that was not being updated. The /etc/ssl/certs is a sym link to /etc/pki/tls/certs and in here these certificates did not have my internal root CA certificate.
It seems that to enforce these other certificates you need to run the following:
update-ca-trust enabled, which enables this to override all certificates to use the extracted ones
update-ca-trust extract, which will extract your custom ca source certifcates into the the combined/extracted certificate path.
It wasn’t until I updated these then did one more gitlab reconfigure that Mattermost would finally recognize the certificates from GitLab.
I’m not sure if this is something that is encoded into Mattermost or possibly one of its dependencies, but this was pretty difficult to track down especially since every system does SSL certificates differently and applications/software all look for these in different ways.
Hopefully this helps someone else or at least provides them with background on the SSL issues since that blog post really helped me figure out the core issue here.
I also had to add my cert file name to /etc/ca-certificates.conf before running update-ca-certificates on Ubuntu 14.04 to get this to work.