Using a self-signed certificate to connect to a VCS server
Overview
This article describes how to make Upsource connect to a VCS server using a self-signed certificate.
Symptoms
When testing connection to the repository you might get the following error:
List remote refs failed: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
or
svn: E200015: Server SSL certificate for `https://my-svn-server:443` rejected
Most likely you are using a self-signed certificate that is not trusted by the Java virtual machine Upsource is running on.
Solution
You will need to import your custom certificate into JVM.
To import the certificate you exported into trust.keystore, run the following command:
keytool -import -alias my-vcs-server-host -keystore <Upsource_dir>internal/java/linux-x64/jre/lib/security/cacerts -file path-to-certificate-file
where my-vcs-server-host is an alias of your VCS server specified in the certificate and <Upsource_dir>internal/java/linux-x64/jre/lib/security/cacerts is the path to the cacerts file inside the Upsource distribution. On Windows it can be found at <Upsource_dir>internal/java/windows-amd64/jre/lib/security/cacerts. If you are running Upsource using your own JVM rather than the bundled one, you should specify the path correspondingly.
Note: the default keystore password of the bundled JVM is changeit
Under Windows it is also possible to install the certificate using a GUI program:
- Download and install Portecle on the server running Upsource. Portecle is a user-friendly GUI application for managing certificates.
- Select Examine SSL/TLS Connection under Examine menu.
- Enter the SSL Host and Port of your VCS server.
- In the newly opened window, click on PEM encoding and save the .pem file.
- On the main screen, click Open an existing keystore from disk icon and select the cacerts file.
- Click the Import a trusted certificate into the loaded keystore icon, select the .pem file that you obtained in step 4 and export it to cacerts.
After that, restart the Upsource server and check if it can connect to the repo.
For more information please refer to the following Oracle article about self-signed certificates.
Please sign in to leave a comment.
Didn't help in my case. I am using certificate issued by my local CA (Win domain CA), and both (domain-root.crt and domain-intermediate.crt) are already imported in "system-wide CA keystore" (.../jre/lib/security/cacerts). And the import is successfull - other Java apps (JIRA, FishEye, SonarQube) are working like charm. But connecting Upsource to Bitbucket server (which is using the cert) is mission impossible.
It is important to say that FishEye, Bitbucket and Upsource are using the same JRE. Other two are validating SSL without problem, but Upsource fails. I know for sure that SSL validation is successfully performed by other two because without root and intermediate cert in system-wide store they are unable to communicate between one another.
Well, the question is why the same cert is OK for some apps, but not for other. Maybe Upsource enforces more strict rules? For example these days trusting root CA is not enough for Google Chrome - although cert's chain is trusted, it will annoyingly red-cross-over-warn that the cert is not OK, with explanation "The server did not supply any Certificate Transparency information." Is it possible that Upsource does such insane certificate checks?
Thanks!
(Btw: as all other JetBrains products - Upsource is great! Congs!)
Btw. Temporary resolved with SSH key.
Where does Upsource keep its trust store? what is its default password? How do we actually run this command without knowing this info?
If someone had problems with the command in linux, try this:
https://upsource-support.jetbrains.com/hc/en-us/requests/755184?page=1
It worked for me :)
Unfortunately, it not worked for me.
I performed as described, and while trying to "test connection" occurred another error:
List remote refs failed: org.eclipse.jgit.errors.PackProtocolException: invalid advertisement of <!DOCTYPE html>
Works for me as written. Using Windows.
Thanks!
Worked for me using keytool on Windows Server 2016 with Upsource 2017.1 connecting to subversion. My certificate wasn't self-signed but still needed to be imported into the Upsource JVM.
This did not end up working for me running from a docker container, BUT the solution was much simpler.
1) run/attach to your docker container
2) run a simple svn command from the docker commandline (i.e. 'svn ls my-server/repo_name')
3) when you get prompted to reject/temporarily accept/permanently accept the certificate, choose to permanently accept it
Then, restart your docker container service. Problem solved!
My above solution no longer seems to work on the upsource docker image. What you can do is this:
1) Export your certificate *.cer file from your VCS server
2) Copy the certificate to your server running docker
3) Copy the certificate to the docker image using docker cp src dest
4) Make sure your upsource container is running. Execute bash as root in the container via docker exec -u 0 -it container_name bash
5) Add your certificate to the keystore via keytool -import -alias my-vcs-server-host -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts -file path-to-certificate-file
Note that these changes will be lost if you recreate the container from the standard image, so you'll probably want to commit the image or build this step into a new image or something.
This works, but why is it needed for SVN servers using a valid LetsEncrypt SSL certificate? Every three months I have to repeat this. Why doesn't Upsource trust LetsEncrypt certificates?
log in as root and keytool is not found. how to fix this? @Troy Tamas
This worked for me, but I'm running a Docker distribution and the change is lost on a container restart. I'll be switching to a ZIP distribution because of this issue.There is a related feature request: "Provide a common place for CA root". Anybody who needs this, please vote for the feature request.
@Dmitriy Korobskiy, I did it next way: get 'cacerts' from the container, import ca-cert, mount upgraded 'cacerts' file. Works well enough.
Mike Interesting. I'm curious about details. So, if I understood correctly: you've created a volume (or a bind mount ?) and mounted an upgraded `cacerts` from a host, which replaced the original `cacerts` in the container? Did you have to delete the original `cacerts` in the container?