Attempting to connect our wiki to JIRA which is only hosted on https. The certificate is valid in a browser, however the certificate is signed by our company and not sure if it's a trusted one on the DekiWiki

JIRA url: https://jira.ourcompany/
username: dekiwiki
password: *****

I can hit https://jira.ourcompany/rpc/soap/jirasoapservice-v2 and get a response 'Hi there, this is an AXIS service!' so I assume the RPC service is working OK (if I change the v2 to v3 it says it can't find it so I guess somethings supposed to be running at that exact URL)

What steps can I take to further diagnose this issue? or most likely, what do I do for dekiwiki to trust the provided certificate? (I won't be able to serve JIRA through http at anytime, I'd have to go through the IT department for that so you can imagine the effort). I do have full access to the DekiWiki box.

Running Deki Wiki 8.05, JIRA Enterprise Edition, Version: 3.12.2-#300

Many thanks

Unfortunately you stumbled into a known problem with no good workarounds. Making remote https calls with certs that are signed by an untrusted party, expired, etc do not currently work from within mono. These requests currently fail.
We've got a bug on this here: http://bugs.opengarden.org/view.php?id=3583

Until it's fixed you can try proxying the request through your local apache using mod_proxy. So it would look like: Deki -> jira extension -> apache via http -> jira via https.

Take a look at how the @api reverse proxy is setup on the deki vm in apache. Same concept.

Ah, bummer.

After further checking, the certificate is valid, and is signed (but not by a root CA like Verison, but by our own company), is there a way I can install this on the wiki box so mono treats this cert as trusted? I'm guessing there's a cert store somewhere which mono uses?

I am having the same sort of problem, I am trying to create an authentication extension that queries an existing database. The call is to be made over ssl via a self signed cert. I have used monos certmgr tool to import both the cert and the root ca. I have tested accessing the site via mono with a test script they provide and it is able to pull the site without a cert error, however the mindwiki api still returns a cert error in the log file when a request is made. Is there a fix for this other than proxying the request?

Thanks

Eric

I haven't had a chance to test it out but there's a good overview that talks about a couple tools (certmgr and mozroots) on Mono's faq
http://www.mono-project.com/FAQ:_Security

Eric, are these the tools you've tried?

certmgr and mozroots don't appear to be anyware on the DekiWiki VM. Guess one way would be to install DekiWiki on a native OS (instead of on the VM), hopefully that version of mono does have these tools

MaxM: Since mozroots and certmgr are not available, I've tried to go with your reverse proxy idea, however so far haven't managed to get apache to play along. Any chance you have a config file lying around with the required settings? I think it would help a few people out on this list.

I've looked at the dekiwiki settings you mentioned but so far haven't made it work

Many thanks.

yes, I have deki wiki installed on a linux os, not using the VM package. The mono tools seemed to run without a problem, infact on the page there is a sample app that tests if mono is able to load a secure website. Before I added my self signed cert and ca the script returned an error, afterwords it ran fine. But mindtouch still does not allow me access to the site. I have just gone ahead and made a localhost vhost that is querying my auth script which is working.

Thanks
Eric

ok, so got this apache reverse proxy thing working, so mono doesn't spew. Here's my /etc/apache2/sites-available/jiraproxy config file:


Listen 8080

<VirtualHost *:8080>
ServerName jiraproxy

ErrorLog /var/log/apache2/jiraproxy.error.log
CustomLog /var/log/apache2/jiraproxy.access.log common

#
# This directive enables the decryption of SSL traffice and requires mod_ssl to be enabled.
#
# To see if your apache server has this turned on, run (lowercase 'L'):
#
# apache2 -l
#
# this will list all your modules. Ff mod_ssl is in this list, then you don't have to do anything
# further (its compiled in). If not, check its available for dynamic linking by running:
#
# a2enmod (Apache2 Enable Module)
#
# If it is not installed, run:
#
# sudo aptitude install libapache2-mod-ssl
#
# then run
#
# ae2enmod
#
# this wil prompt you which module to enable. You should get an option of 'ssl'. Type in ssl
#
# restart apache
#
# /etc/init.d/apache2 restart
#
#
SSLProxyEngine on

### mod_proxy rules ###

ProxyRequests Off
ProxyPass / https://jira.mycompany.com/ retry=1
SetEnv proxy-nokeepalive 1

# We can put rules in here to only allow requests from certain hosts
# however, since we are _only_ proxying to _one_ host then we don't
# have the danger of being an open relay
<Proxy *>
Order deny,allow
Allow from all
#Allow from localhost
</Proxy>

</VirtualHost>

You need to make a link /etc/apache2/sites-enabled/jiraproxy to point to the file above

Also need to edit /etc/apache2/sites-available/dikiwiki and change the '*' in <VirtualHost *> to <VirtualHost *:80>

Now in your dekiwiki JIRA config you put 'http://jiraproxy.localdomain:8080/' in as your JIRA url.

Oh, and you'll have to put '127.0.0.1 jiraproxy.localdomain jiraproxy' in the Deki VM /etc/hosts file

This will only show you what the JIRA plugin pulls from JIRA, it won't allow you to browse the issue unless your JIRA install allows anonymous access (in which case unlikely to have SSL enforced like this)

Thanks for all your help guys. Hopefully when I move the wiki to it's own native run OS I won't need to do this

I just noticed that the Mantis bug at http://bugs.developer.mindtouch.com/view.php?id=3583 for this issue has been closed with a "won't fix" resolution. The closer states that the problem was that the root certificates were not installed, and that misses the point.

Based on the discussion in this thread, the JIRA plug-in for Deki Wiki cannot use an https URI no matter what. In my scenario, I have installed my local root CA certificate such that the Debian host trusts it. In fact, I can use wget to grab a page from the site without issues. But the JIRA plug-in fails. Another user on this site said that using the mono tools also did no good.

Using a reverse proxy running on the wiki server is a workaround, but the solution offered by bertvanbrakel seems problematic to me because it exposes encrypted content across his local network. That may be acceptable in some environments, but if I bother to use SSL with something, I generally do not want it flowing in the clear over my internal or external networks. Since the JIRA plug-in produces URLs used in auto-generated links, the proxy needs to be available to all wiki client systems if those links are going to work.

I implemented a somewhat klunky workaround, but I would love to get rid of it in favor or something simple that allows Deki Wiki to query JIRA over SSL.

1. My JIRA server happens to have an Apache port 8080 redirect to the secure page. You could also create this anew on any port that you want.

Note that this is on the JIRA server--not the wiki server! Also make sure that the mod_alias Apache module is installed.

2. I edited the /etc/hosts file on my Deki Wiki server so that jira.company.com resolves to the the local server (localhost):

3. I changed the ProxyPass command in bertvanbrakel's solution so that it uses the real IP address of the JIRA server rather than its name.

That generates an SSL error since the certificate is for the name jira.company.com and not 10.0.0.1. Fortunately, whatever does the querying for the JIRA plug-in is happy to ignore this error.

I also restricted proxy access to localhost:

5. In the JIRA plug-in, I configure the URL to be:


The end result is this:
-The JIRA plug-in for Deki Wiki can access JIRA by "talking to itself" via the proxy at http://jira.company.com:8080. These communications are not encrypted, but they never leave the machine (one service is just talking to another), so that is not a huge security issue.
-The JIRA plug-in produces wiki links with URLs like http://jira.company.com:8080/blah.
-When other machines access http://jira.company.com:8080, they are redirected to the real JIRA server, which redirects to the real HTTPS URL without the intervention of a proxy.