xml-rpcbugzillaservicehostversionone

VersionOne Bugzilla Integration "Validation Failed"

I am trying to set up the VersionOne-Bugzilla integration tool (https://community.versionone.com/VersionOne_Connect/Supported_Integrations/VersionOne_Integration_for_Bugzilla_5.0_and_Above), and I am hitting one problem when trying to set up the ServiceHost configuration. On the Bugzilla Service Settings tab, I can't get a successful validation. Here is what I a picture of what my error message looks like and below that is what I'm entering:

Validation failure

Bugzilla URL: https://<domain>:<port>/xmlrpc.cgi

Username: <Confirmed Username (w/ admin permissions + edit/view bug permissions)>

Password: <password>

The above URL (without the xmlrpc appended) gets me to Bugzilla. This is not a new installation by the way, we have used this for a while. I have also used this same format with /rest appended to successfully make calls to the REST API before. I also tested manually logging in with this user and got in fine. In the documentation, the URL example shows appending "/rest" instead of "/xmlrpc.cgi", which wasn't validating either (with or without ignore certificate checked). It wasn't until I downloaded the latest release from 2 days ago and tried using the updated version that I saw the "/xmlrpc.cgi" being appended instead. After seeing this in the config file and seeing in the documentation that the tool needs Bugzilla to be set up for RPC, I went down the path of researching it, and saw that I was missing some modules for RPC in Bugzilla. I installed the following four:

SOAP-Lite

XMLRPC-Lite

JSON-RPC

Test-Taint

Running checksetup.pl for Bugzilla shows that all 4 are found. After this, I used the tool here (https://docs.devzing.com/bugzilla-xml-rpc-client/) to test a version call, and I got the following result:

Bugzilla XML-RPC successful return

Now I'm left confused. I have verified that the user can access Bugzilla, and I have installed the optional RPC modules + verified that an XMLRPC call to Bugzilla works, yet the ServiceHost tool is still failing to validate. What am I missing/doing wrong? Is this validation attempt logged anywhere for more information? Thank you!

Update: after trying to do some tracing with Fiddler, I made an adjustment to the Fiddler settings to handle HTTPS. Once that was done, the validation succeeded whenever Fiddler was tracing traffic. Anything less than these options and the validation would still fail. The moment I close Fiddler and try to validate again, it fails. It seems that there is some issue with the tool's handling of HTTPS. Also note that I did switch back to using "/rest" in the URL and "ignore certificate", but those alone didn't fix the problem as I stated earlier that I already tried those and they weren't the sole solution. Is there some change I can make to the ServiceHost tool to make this run correctly without Fiddler?

Validation success

Solution

  • The problem ended up being that OpenSSL was outdated and needed to be upgraded from our old 0.9.8 release to 1.0.1+. In 1.0.1+, they added support for TLS v1.1 and v1.2.

    The upgrade was pretty smooth (note this is on Windows Server). I needed to replace 2 DLLs: libeay32 and ssleay32, as well as the openssl executable in the Apache bin folder. As Mark Irvin said in his response, make sure you back up anything you'll be altering beforehand. Once that was done, I hit one error when trying to get Apache/OpenSSL back up and running, and it was that I was missing a newly required DLL with the new version of OpenSSL. Once I downloaded and installed it from Microsoft's site, Apache ran smoothly again and I am now able to complete a connection to Bugzilla in the tool without Fiddler.

    From telerik.com, this is the reason why Fiddler made it work:

    Running Fiddler resolves such problems because Fiddler, by default, only uses SSLv3.0 and TLSv1.0 when communicating with HTTPS servers, avoiding the compatibility problems seen on legacy servers. If your computer has the .NET Framework v4.5 installed, Fiddler v4 can be configured to attempt to use TLS/1.1+ which will lead to the same connection failure seen when Fiddler wasn’t present.

    To resolve this issue, either disable TLS/1.1+ on the client, or better yet, nag the server operator to upgrade their software to support the TLS standard.