Self signed certificates on Git server cause errors

[barsema]

We use a self signed certificate on our GIT server, this will cause an error and a failure to check out the repository.

Workaround is to add the CA to the embedded JRE using the keytool utility but this is a pain.

I read that Jgit version 4.9 has a better handling of the ssl errors see:

https://github.com/eclipse/jgit/commit/d946f95c9c06f27de8aac6ecc3f5d49eabe6e030

So perhaps upgrade Jgit to 4.9?

[Phillipus]

I can certainly upgrade to JGit 4.9. Haven't looked to closely at what else would need to be done. @barsema can you test if I create a build?

[barsema]

Sure! that would be great

[Phillipus]

This build uses JGit 4.10. I haven't changed any code.

org.archicontribs.modelrepository_0.3.2.201802051901.zip

[barsema]

Thanks for the prompt reaction, unfortunately there is no immediate change in behavior, it still throws the error without options to ignore. Perhaps some handling of the UI is needed.

[Phillipus]

Do you have to change a setting in the git config file for the model repo?

[barsema]

I'll test that out

[jbsarrodie]

Hi,

From what I can see/understand, the whole point is not to have JGit automatically manged certificate errors, but more to have our plugin to detect such issue and continue if the user accept to not verify a certificate (because it is self signed or coming from a local PKI).

JGit implementation seem to check for the http.sslVerify git flag, so you can test by manually setting it to false in the right local git repository. If this work, then configuration panel should be updated.

[barsema]

Modifying the git config does not seem to work.

[Phillipus]

I need to simulate the situation so I can debug and trace what's going on. Can someone tell me how to do this?

[barsema]

I guess you could try removing (renaming) the cacerts file in the JRE (lib/security) that way no ssl connection will validate.

[jbsarrodie]

@Phillipus with GitBlit you should be able to enable SSL, and in this case this will be a self-signed one.

BTW - GitBlit seems no longer maintained, another good option for our tests is Gitea. Basically you download it (one single exe) and then run it with ./gitea web. See doc for more info. It works on all OS and support SSL.

Then, if you create a repo on GitBLit/Gitea and tries to access it from Archi using the HTTPS url, it should fails.

[Phillipus]

When using GitBlit I set my global .gitconfig file with this entry:

[http] sslVerify = false

Is this relevant?

[jbsarrodie]

When using GitBlit I set my global .gitconfig file with this entry: [http] sslVerify = false Is this relevant?

If you mean you set it in the .gitconfig of the repository inside gitblit then this is not relevant. This has to be set on "client side": in the local clone (done by Archi) of the repository/model.

[Phillipus]

No, in my global .gitconfig file (In User/Home). I remember I had to set this for GitBlit to work but I can't remember why.

[jbsarrodie]

I wonder if the reason why you added it was not simply because that was not working otherwise through https. I know we discussed about this issue at the very begining (but I don't have access to my old emails for the moment).

A simple way to see if there's a relation is to check if you can import a model from gitblit using https now, and then remove this config and test again. If it works the first time and not after then this is the right setting.

[Phillipus]

Yeah, I just tried to pull from the local GitBlit server with it set to false and I get the TransportException as expected. But reading the fix at https://github.com/eclipse/jgit/commit/d946f95c9c06f27de8aac6ecc3f5d49eabe6e030 it seems that all that is doing is exposing the error to the user? So setting it to true in .gitconfig should allow it?

[jbsarrodie]

So setting it to true in .gitconfig should allow it?

Yes, but we should add a way for the user to set this flag through the UI. Doing it manually just be just a workaround for the moment.

In fact the more I use our plugin, the more I think we should rework the way it is configured:

• Configuration in the preferences should be mainly defaults or things that influence all models (=repositories). We could add a way to manage add/remove certificates from a dedicated truststore.
• Model/repositories properties should allow to override more settings, like whether or not to use the proxy (together with its configuration), and whether or not to check for SSL certificates.

[Phillipus]

Yes, I understand that, but @barsema is saying that setting it to "false" makes no difference. So there's no point in exposing it in the UI if something is not working.

Edit - "false", not "true"

[jbsarrodie]

@Phillipus did you try setting it globally or locally in the repository of the cloned model ?

@barsema How did you exactly try ? The common mistake is to add http.sslVerify = false to your .gitconfig while it should be a new section like that:

[http]
sslVerify = false

[Phillipus]

@jbsarrodie Either. It works globally or locally.

[barsema]

I tried the local config only (not sure where I should put the global config for Jgit to find) If I access the repository from source tree (a git UI by attlassian) the setting does take effect.

Could it be you guys have an actual git installation on your machine and that jgit somehow uses that? (I have no GIT other than the ones embedded in source tree and in Archi

[Phillipus]

It shouldn't make any difference if there is a git installation. At this stage, we need to find whether the setting in the config file of the local repository :

[http]
sslVerify = false

makes any difference. So you are saying that it affects SourceTree but not Archi?

[shadow31]

I'm using GitBlit as well and no matter what I do, I still get the error. I've included the self signed cert into the cacert of JRE and it still prompts the same error. I've also included the same cert in the cacert file of gitblit, no luck. Then further I included the Cert Authority cert to complete the chain thinking the CA is not trusted but no luck in there as well.

Any other ideas?

[barsema]

@Phillipus Yes, exactly, I do not get the error in Sourcetree but do in Archi. with that exact config setting.

[jastone90]

Has anyone found a way around this issue? Running into it now.

[davidsara]

Hello, I've prepared steps to reproduce this:

• download Gitea
• run gitea cert --host [HOSTNAME] to generate self-signed certificate
• setup ssl - https://docs.gitea.io/en-us/https-setup/
• run gitea web
• create new empty repo
• try to add local model to workspace, should get following error

[http] sslVerify = false in global .gitconfig is set, but no effect.

Hope it will be useful :)

[farflungfish]

@davidsara @jastone90

Archimate has an embedded JRE (on my computer it is under: C:\Program Files\Archi4\jre\

Java uses a keystore called cacerts to verify the certificate which your application presents. It appears that your Archimate JRE keystore does not contain your self-signed certificate or the certificates in the chain to your trusted CA. (c:\Program Files\Archi4\jre\lib\security\cacerts is where I found it, the password is just "changeit".

I solved this by using keytool, which is in the directory C:\Program Files\Archi4\jre\bin

C:\Program Files\Archi4\jre\bin>keytool -import -trustcacerts -alias CA -file "path\to\cert.cer" -keystore "c:\Program Files\Archi4\jre\lib\security\cacerts"

[jbsarrodie]

@farflungfish Thank you for putting this information here, it might help people that discover this issue.

FWIW, this is also described in this wiki page

[davidsara]

@farflungfish Thank you very much! Works like a charm!

[WatchTh1]

I think there would be nice thing to add a way to manage following options:

-Djavax.net.ssl.trustStore=/home/user/SSL/my-cacerts -Djavax.net.ssl.keyStore=/home/user/SSL/server_keystore.jks

So user could select wether to use built in keystore or systemwide, managed by domain admins with all trustcerts imported by default.

PS: Full options list to may be of use:

-Djavax.net.ssl.keyStore specifies the keystore file. -Djavax.net.ssl.keyStorePassword specifies the passphrase of the keystore. -Djavax.net.ssl.trustStore specifies the truststore file to use to validate client certificates. -Djavax.net.ssl.trustStorePassword specifies the passphrase to access the truststore file.