Good day.
I'm trying to realize integration Jenkis/Bitbucket Server/Jira Server.
All servers are working under SSL (Private PKI) with Peer authentication enabled.
So first step is to connect to BitBucket and it was successfull.
Everything i've done is added JVM_ARGS to jenkins
-Djavax.net.ssl.keyStoreType=pkcs12
-Djavax.net.ssl.keyStore=/ssl/jenkins.p12
-Djavax.net.ssl.trustStore=/ssl/cacerts
-Djavax.net.ssl.keyStorePassword=JenkinsPassword1
-Djavax.net.ssl.trustStorePassword=changeit
So Jenkins authenticated on BitBucket.
After that i tried to connect Jenkins to JIRA. And without a success.
Caused by: javax.net.ssl.SSLException: Received fatal alert: bad_certificate
All servers have certificates deployed under same CA chain.
All servers have that chain in trust store.
So i wonder what i'm doing wrong?
I've enbled SSL debug (javax.net.debug=ssl).
And saw follwing strings during jira site configuration validation:
Found trusted certificate: //So there is no problem with truststore.
....
....
Warning: no suitable certificate found - continuing without client authentication // WHY??
*** Certificate chain
<Empty>
***
But with bitbucket server it picks right certificate.
Double cheked everything, moreover, bitbucket server is working good.
Some dig in code i found that JIRA Plugins uses Attlasians Library, which is uses Apache HTTP Client. And i could not understand why HTTP Client not initializing keystore for JIRA Connection.
May be someone faced same problem? Any solution without rfactoring Plugin or libraries?
Any suggestions are welcome.
I'm using Jenkins 2.89.2 with Jira Plugin 2.5 /Bitbucket Server 5.3/ Jira 7.63
Jenkins running in docker.
PS: Skip Certificate Verification Plugin not an option. Peer authentication is mandatory.
We have teamcity 10 running as a service behind a corporate network and we need to configure it to connect to a proxy so we can access an external issue tracker (Jira).
When we attempt a test connection we get
Error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I am assuming that is because the proxy isn't setup properly? Other links seem to suggest its a certificate issue for Jira Cloud? Alternative theory based on this https://confluence.jetbrains.com/display/TCD7/JIRA and https://developer.atlassian.com/jiradev/latest-updates/soap-and-xml-rpc-api-deprecation-notice suggest that xml-rpc is required for the integration however that is deprecated?
We have added
TEAMCITY_SERVER_OPTS in environment settings with the following
-Dproxyset=true;-Dhttp.proxyHost=xxx;-Dhttp.proxyPort=xxx
Is there anything else? Or a simpler way?
Thanks for reading
Most probably the HTTPS certificate of your Jira is self-signed, so you will need to configure TeamCity server JVM by adding the root certificate of your organization into JVM keystore as trusted.
I am working on integrating Cloud Connect with our platform's REST APIs. I am receiving an error when trying to connect to our development servers using the REST connector:
Component [REST Connector:REST_CONNECTOR] finished with status ERROR.
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Our development environment uses a self-signed SSL certificate, which I suspect is at the heart of the issue. How might I go about resolving this issue?
I am afraid that when running the graphs on GoodData servers, there is no way you could configure them to trust your self-signed certificates.
If you would be running the graph locally however (which should be OK for development), adding that certificates (or certification authority) to trusted certificates on your local machine should do the trick (and restarting CloudConnect after it, just to be sure it is reflected).
For some of my site visitors, the SSL certificate is failing. Whatever tests I do on various browsers for me the SSL certificate is valid.
I can't think of how to test this on client side, and to identify the problem.
How would you do this?
One client gets: fatal certificate unknown
While RouMao's answer is mostly correct, he has missed what is (IME) the most common problem with SSL certificates - the certificate you are using requires an interim certificate from the CA which you have not included in your certificate chain. Most CAs provide an online tool for analysing the certificate - try the one located here.
Also, is there any correlation with which browser being used? Notably, Chrome does not handle SSL v2 by default
Most of the failing of SSL certificates were caused by visitors themselves. Somehow could not tests or verified by server implementation.
Here are some obvious examples:
Your cert is validated since April 1st 2012, but the client's local machine time is set to 2010 -- one year later than current time. In this case, the visitor should encounter problem all the times, until his machine time is later than April 1st 2012.
visitor is behind a restricted firewall. The firewall could terminate the SSL/TLS connection and re-crypt the link with a pseudo/self-sign certificate. Indeed this could be considered as a man-in-middle attach.
The Trusted Root Certification was removed by client himself
it is very hard to fix all these problem. Sometimes, you need to create a client side native application to detect or fix all the possible problems, and require client browser to execute the application each time before it enter the HTTPS mode.
P.S. most of the e-bank application do like this.
We're having an issue with securing an intranet / internet website with SSL where
we can't know the qualified domain name in advance.
Basically, I'm trying to make a program that will be installed on a webserver
outside my direct control, to be accessable over intra- or internet. In either case
I want it to be secure via SSL (https). To do this, I would like to include and
install a SSL certificate on the target machine. My installer is fully prepackaged
and should not require any particular during- or postinstall intervention from my
end. Problem is, I can't know ahead of time the target machine's name or domain
name, so as far as I can tell the SSL connection will be returning warnings (or
worse?) when accessed, since the certificate I include will (must) have a different
name on it.
I really want to avoid those warnings, but I still want to keep it secure. Is there
any way to install a SSL connection without certificate warnings without the domain
name known ahead of time?
Thanks for any help you folks can give.
What you want to do is not possible. Here's why.
A certificate will include a set of names (Common Name, possibly along with Subject Alternative Names, possibly including wildcard names).
The client's web browser will do the following:
The user wanted to visit "https://myapp.mydomain.com/blog/posts/1".
The request is via SSL and the domain name in the request is "myapp.mydomain.com".
Get the certificate from the Web server.
Ensure that at least one of the names in the certificate is exactly equal to, or wildcard-matches, the domain name in the request.
Display the page.
Therefore, you need a certificate with the exact domain name (or a wildcard matching the exact domain name) by which the application will be used. And the certificate needs to be available at the same time as, or later than, the time when the exact domain name of the website becomes known, and cannot be made available any earlier.
You seem to be under the misapprehension that somehow a certificate can "create" or "install" an SSL connection. That is false. The Web server - Apache, IIS, Nginx, LigHTTPD, or whichever one you happen to use - is the program that knows how to every aspect of SSL connectivity. The certificate is just a file that the Web server sends to the client, without even opening or using in any way.
Additionally, the author of a webapp to be distributed is not responsible for creating or distributing certificates, and should not be under the misapprehension that he is responsible. Only the website maintainer should be responsible for obtaining a certificate for his website. As another person remarked, in your installation process or perhaps in a post-installation process, you may ask the person installing the webapp for a certificate. But that is the best you can do.
The best you can do is to buy a wildcard SSL certificate - but wait, it's not what you think. You still need to know the second-level domain (the TLD being ".com") ahead of time. You can effectively ask for a cert that covers *.foo.com - then any site, a.foo.com, b.foo.com will be covered. Of course, these certs are more expensive that FQDN certs because you are doing the buggers out of some extra coin.
-Oisin
Each of those sites should have their own SSL certificate. Why not prompt the user to provide the cert file during installation?
In most (if not all) cases, the SSL certificate is associated with the webserver (apache, IIS, etc.) and is not part of your application. It's up to the admin of the web server to install the certificate and not you as the author of the program.
If your installation program does have the ability to modify the web server configuration, and you are willing to have it use a self-signed certificate, you can script the creation of the certificate to allow the domain name to be input. However, I sense this is not really available to you. Also, a self-signed certificate will generally cause certificate warnings.
If I understand you correctly there might be a solution to your problem now. This solution won't help you, however, if you have no control over specifying what SSL certificates are served from the web server where your program is installed (as mentioned by someone else). If your program itself contains a web server you won't have this issue.
If you start with a trusted https website, you can make cross-domain TLS (SSL) XmlHttpRequests to the web servers that are running your application. This is made possible using the opensource Forge project. The project uses a TLS implementation written in JavaScript and a small Flash swf to handle the cross-domain requests. Your program will need to serve an XML Flash policy file that grants the trusted website access to the web server running the application.
Your program will also need to generate a self-signed SSL certificate and upload it to the trusted website. From there, each program's certificate can be included as trusted via the JavaScript TLS implementation. Alternatively, you can have your program upload its certificate to be signed by a CA you create, using a common or subject alternative name that is appropriate for your use (it doesn't have to be the domain name). Then you can use JavaScript to trust the CA certificate and look for the correct name on each certificate.
For more details check out the Forge project at github:
http://github.com/digitalbazaar/forge/blob/master/README
The links to the blog posts at the end provide more in-depth information about how it works.