Bugzilla – Full Text Bug Listing
| Summary: | Can't connect to jira over https | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> |
| Component: | Mylyn | Assignee: | Eugene Kuleshov <ekuleshov> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | age.mooy, axb, brockj, thione |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | 0.9 | ||
| Hardware: | PC | ||
| OS: | All | ||
| URL: | http://developer.atlassian.com/jira/browse/JDB-108 | ||
| Whiteboard: | |||
Not sure how to do this with Axis, but commons HttpClient allows to specify custom SSL ssocket factory and you can use EasySSLProtocolSocketFactory that allow to authenticate with a self-signed certificates. See http://jakarta.apache.org/commons/httpclient/sslguide.html Brock, can you please look at this? The only workaround for this right now is to fetch SSL certificate from http connection and manually import it into the default key stire, which is very inconvenient and ugly. You will also notice that EasySSLProtocolSocketFactory is *not* for production use. Certificates are there for your safety, ignoring an invalid certificate is not a smart idea. The workaround is not as complex as you make it sound. It only has to be done once and not at all if you have your certificate signed by a valid CA. If you don't care about security, don't use SSL. If you are in a corporate environment and can't afford a valid certificate, why not make your own root CA certificate and install that on all machines. Any certificate signed by that root certificate will then be considered valid. A better approach would be to maintain a private keystore and prompt the user when an invalid certificate is encountered (adding it to the private keystore if accepted). I don't have the time to implement this, but patches would be considered. (In reply to comment #3) > You will also notice that EasySSLProtocolSocketFactory is *not* for production > use. Certificates are there for your safety, ignoring an invalid certificate > is not a smart idea. The workaround is not as complex as you make it sound. > It only has to be done once and not at all if you have your certificate signed > by a valid CA. If you don't care about security, don't use SSL. I don't care about security and yet I have no option to not use SSL. Jira server is not kind of thing where I need to be paranoid like that, so solution like EasySSLProtocolSocketFactory should be acceptable. > If you are in a corporate environment and can't afford a valid certificate, why > not make your own root CA certificate and install that on all machines. Any > certificate signed by that root certificate will then be considered valid. This is the troublesome part. I have to get to owners of that server and request this certificate, then I have to copy this certificate into every JRE instance that can be used to run Eclipse... on every machine around. Well, I don't consider this a natural task, especially for not critical content such as Jira access. > A better approach would be to maintain a private keystore and prompt the user > when an invalid certificate is encountered (adding it to the private keystore > if accepted). I don't have the time to implement this, but patches would be > considered. Such keystore already provided by Eclipse platform and I would be happy to look at the UI part if you can tell me how to make Axis to use custom SSL factory. I'll assume that you guys are looking into this. Eugene, if you aren't able to resolve it we should at least get your experiences/instructions into the FAQ (perhaps moving the FAQ to the Wiki if that makes it easier). An issue should be created in the Jira dashboard issue tracker for this one as nothing can be done in Mylar to fix it. Fixing this issue isn't as simple as it looks. It requires writing a socket connection factory for Commons HTTP client and a HTTP Sender for Axis (extending the Commons HTTP Sender). It might be possible to store certificates in the Eclipse key chain, but it wasn't designed for it. (In reply to comment #6) > An issue should be created in the Jira dashboard issue tracker for this one as > nothing can be done in Mylar to fix it. Are you suggesting that we should create it for you? :-) > Fixing this issue isn't as simple as it looks. It requires writing a socket > connection factory for Commons HTTP client and a HTTP Sender for Axis > (extending the Commons HTTP Sender). It might be possible to store > certificates in the Eclipse key chain, but it wasn't designed for it. Strange. It seems SVN and CVS are storing this stuff anyways... (In reply to comment #5) > I'll assume that you guys are looking into this. Eugene, if you aren't able to > resolve it we should at least get your experiences/instructions into the FAQ > (perhaps moving the FAQ to the Wiki if that makes it easier). Mik, I wouldn't advice anyone to do what I did. Basically even if I could get an SSL key from the server owners there is good chance that it would be in some format that java keytool won't understand and one would require some 3rd party tool to import it. In my case I can't get it from admins, so I fetched it from the http connection. then keytool failed with NPE on import, so I had to write another tool to read certstore and append fetched certificate there. SVN stores them in their own key store (JavaHL and JavaSVN store them in different places). Not sure what CVS does (think it saves them in a .ssh folder in your home directory). easy way to install a certificate: Go to the site with IE Accept certificate go to internet options | content | certificates... Export the certificate as der encoded .cer format import it into java's ca keystore (keytool -importcert -file <file.cer> -alias <alias> -trustcacerts When prompted for a keystore password enter "changeit" (this is all from memory, so may be a bit wrong) (In reply to comment #9) > SVN stores them in their own key store (JavaHL and JavaSVN store them in > different places). Not sure what CVS does (think it saves them in a .ssh > folder in your home directory). I am pretty sure JavaSVN added support for Eclipse key chain and for some reason also thought that CVS had it all the time (no it does not save this stuff in .ssh folder) > easy way to install a certificate: > Go to the site with IE > Accept certificate > go to internet options | content | certificates... > Export the certificate as der encoded .cer format > import it into java's ca keystore (keytool -importcert -file <file.cer> -alias > <alias> -trustcacerts > When prompted for a keystore password enter "changeit" > (this is all from memory, so may be a bit wrong) Haven't tried with IE and FireFox does not have export. Ayways, I wouldn't recomment anyone to mess up with default cert store... (In reply to comment #10) > I am pretty sure JavaSVN added support for Eclipse key chain and for some > reason also thought that CVS had it all the time (no it does not save this > stuff in .ssh folder) version 0.8.6 ... + SVNClient: auth info is stored in Eclipse key ring when used within Eclipse. http://svn.tmate.org/repos/jsvn/tags/1.1.0.beta2/changelog.txt However you are right about CVS ssh2 support. It does store ssh keys in <home>/ssh folder by default. Probably for interoperability with the command line cvs client. I assume you mean EclipseSVNAuthenticationManager (in JavaSVN). It does use the platform authorization info stuff, but iy doesn't store the certificate, just the location of it. The point is there doesn't appear to be a common trust manager for Eclipse. JavaSVN has two different places it can store certificates, JavaHL has another and CVS has yet another. It looks like something may come out of the equinox project: http://www.eclipse.org/equinox/incubator/security/EJS/rcp/keystore.html Using an always accept trust store is an option, so long as it doesn't affect anyone else using Commons HTTP Client or Axis. So no setting of global socket factories or system properties. By the way, bug 144256 seem related. https://bugs.eclipse.org/bugs/show_bug.cgi?id=144256 Yes, Brock you may want to look at that because Nathan fixed this problem in Bugzilla by providing a ProtocolSocketFactory. You can retrieve a context or just look at the patch (if you feel like squinting). Eugene, are you going to file a JIRA bug for this? If so you can mark this one for LATER so that we remenber to follow up at some point. I sort of wish we could mark as blocked by the JIRA issue, or clone this as a JIRA issue, one day... (In reply to comment #15) > Eugene, are you going to file a JIRA bug for this? If so you can mark this one > for LATER so that we remenber to follow up at some point. I sort of wish we > could mark as blocked by the JIRA issue, or clone this as a JIRA issue, one > day... I'd prefer not to close it. Maybe Brock will have chance to fix it the same way as done for Bugzilla even so he is against this way of doing that. See his comments at http://developer.atlassian.com/jira/browse/JDB-108 bug 144256 has the right idea, but it doesn't work in one very specific case (which Jira uses). If the server returns you a redirect response code and you are using automatic redirection the custom protocol handler is lost because the redirect URI is absolute, not relative. This may be a bug or a feature in HTTPClient. Axis is also using HTTP Client incorrectly which makes it impossible to use per hsot protocol configurations (they are using absolute URIs). Working around this bug requires copying the entire CommonsHTTPClient class and making a few small changes. Registering a global protocol handler would fix both of these cases, but would prevent us ever using a shared HTTPClient plugin. For now it might be best to go with registering a global handler and adding another issue to fix it up at some point. Where do we stand with this? Should we add a FAQ entry for the time being? I have tried quite a few options, but none of them worked fully. For me to fix this properly will require a large amount of re-writing. I am very tempted to just wait and see what comes out of the equinox security project. They might come up with an eclipse managed trust store that overlays the JDK one and is responsible for prompting the user to accept new/untrusted certificates. FOr now it would be best to just have an FAQ for this one. It would be great if you could add a note to the FAQ on this. To make this easier I just turned the FAQ into a Wiki: http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting Also note that we just generalized the Bugzilla Connector's SSL support in mylar.internal.tasks.core.UrlConnectionUtil and have a socket factory and trust manager. (In reply to comment #20) > Also note that we just generalized the Bugzilla Connector's SSL support in > mylar.internal.tasks.core.UrlConnectionUtil and have a socket factory and trust > manager. HttpsURLConnection.setDefaultSSLSocketFactory(ctx.getSocketFactory()); Doesn't seem a good idea to me. It is probably better to use common httpclient instead. *** Bug 150175 has been marked as a duplicate of this bug. *** I just sarted experimenting with Mylar (0.7). We have a Jira repository that uses SSL with a self-signed certificate. I have imported the root certificate into the certificate store of the JRE that is running eclipse but I still get the "SunCertPathBuilderException: unable to find valid certification path to requested target" exception. Is there any workaround for this I can use until this issue is resolved ? Importing certificate is the workaround. You need to make sure that you imported certificate using correct alias. What is the "correct alias" ? Could you please give a little more detail on how to to this ? Alias is the same as your host name. (In reply to comment #26) > Alias is the same as your host name. > How do I do this ? I have a server certificate that I've imported into my JRE store using the keytool. I've looked inside and it has no hard domain names in it. I DO know that the Jira server I'm connecting to has multiple domain names but I don't kow which one the JRE is complaining about, (In reply to comment #27) > (In reply to comment #26) My apologies. I forgot to also import the signing certificate as a trusted signer. The Jira repository works fine now. Sounds like this would make another good FAQ entry (http://wiki.eclipse.org/index.php/Mylar_FAQ). It would be much better to fix this issue. I wouldn't recommend to mess around with default keystore... I hope to look at this next week, unless Brock have chance to. Eugene, assigning to you for now since I'm not sure if/when Brock will get to it. I attached working patch to jira soap services at http://developer.atlassian.com/jira/browse/JDB-108 Great. Brock: can we have that patch applied by early next week so that we can get this into the Mylar 0.9 release? Brock: any news on this patch? More people are encountering this problem. *** Bug 164265 has been marked as a duplicate of this bug. *** Eugene: it looks like Brock has applied the patch. Could you synch org.tigris.jira.* and check? (In reply to comment #36) > Eugene: it looks like Brock has applied the patch. Could you synch > org.tigris.jira.* and check? Right. He did applied my patch and also did few other fixes (including evil hack for reading proxy setting from http.proxyHost and http.proxyPort system properties). Jira services 0.9.3 is on his update site. So, you may be able to check it yourself... I've tested with code from the HEAD and latest jira services from svn and now I don't need to import certificate. So it is resolved. That's really great Eugene, this one was really getting in a lot of peoples way. And thanks for getting the patches applied in time for our next release Brock. The fix is in dev build 0.9.0.v20061124-0730, which should be available in 15-30 min. If anyone else having this problem could try it out and verify that would be great: http://www.eclipse.org/mylar/dl.php Eugene, could you take a quick pass at updating any stale instructions in this FAQ section? http://wiki.eclipse.org/index.php/Mylar_FAQ#JIRA_Connector_troubleshooting I can't verify most of the stuff from that section, but if all of it working, then page is correct. :-) |
I am getting the following error when trying to connect to Jira repository that is using https protocol (server was upgraded to Jira 3.6.2-#156). It seems like http protocol is disabled there. Another trouble is that JiraServerFacade.validateServerAndCredentials() method returns true/false and does not show the real error. I believe method should be void and it shoud rethrow exception. So, "validate connection" would be able to actually tell why user can't login. org.tigris.jira.core.service.exceptions.ServiceUnavailableException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at org.tigris.jira.internal.core.service.soap.SoapJiraService.getServerInfo(SoapJiraService.java:161) at org.tigris.jira.core.service.CachedRpcJiraServer.initializeServerInfo(CachedRpcJiraServer.java:378) at org.tigris.jira.core.service.CachedRpcJiraServer.getServerInfo(CachedRpcJiraServer.java:427) at org.tigris.jira.core.ServerManager.testConnection(ServerManager.java:116) at org.eclipse.mylar.internal.jira.JiraServerFacade.validateServerAndCredentials(JiraServerFacade.java:132) at org.eclipse.mylar.internal.jira.ui.wizards.JiraRepositorySettingsPage$1.run(JiraRepositorySettingsPage.java:79) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) Underneath failure is: AxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: 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 faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace: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 at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1476) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:847) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:815) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:619) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:502) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.axis.transport.http.CommonsHTTPSender.invoke(CommonsHTTPSender.java:196) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) at org.apache.axis.client.Call.invokeEngine(Call.java:2784) at org.apache.axis.client.Call.invoke(Call.java:2767) at org.apache.axis.client.Call.invoke(Call.java:2443) at org.apache.axis.client.Call.invoke(Call.java:2366) at org.apache.axis.client.Call.invoke(Call.java:1812) at com.contegix.atlassian01.rpc.soap.jirasoapservice_v2.JirasoapserviceV2SoapBindingStub.getServerInfo(JirasoapserviceV2SoapBindingStub.java:1635) at org.tigris.jira.internal.core.service.soap.SoapJiraService.getServerInfo(SoapJiraService.java:159) at org.tigris.jira.core.service.CachedRpcJiraServer.initializeServerInfo(CachedRpcJiraServer.java:378) at org.tigris.jira.core.service.CachedRpcJiraServer.getServerInfo(CachedRpcJiraServer.java:427) at org.tigris.jira.core.ServerManager.testConnection(ServerManager.java:116) at org.eclipse.mylar.internal.jira.JiraServerFacade.validateServerAndCredentials(JiraServerFacade.java:132) at org.eclipse.mylar.internal.jira.ui.wizards.JiraRepositorySettingsPage$1.run(JiraRepositorySettingsPage.java:79) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145) at sun.security.validator.Validator.validate(Validator.java:203) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172) at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:840) ... 33 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236) at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194) at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216) ... 38 more