ROS vs. Linux: Making It Work

Posted in Rants by AST on Sunday, January 28th, 2007

Amoxil Generic Buy Clarinex Online Neurontin Without Prescription Topamax No Prescription Soma For Sale Glucotrol Generic Buy Aricept Online Stromectol Without Prescription Lotrisone No Prescription Celexa For Sale
Updated 2007-24-05: After trying to do this again, I realized that I left out some pretty crucial stuff that cost me about 30 min to try and find again when I was setting up a new machine. Apologies for this. — ast

I finally completed the convoluted identity proofing process required by the Irish Revenue Commissioners’ Revenue Online System (ROS) so that I could view/file all of the necessary tax forms for Archistry myself. The registration process/identity proofing for business customers theoretically involves the following 3 steps:

  1. Application for a ROS Access Number
  2. Apply for your digital certificate
  3. Retrieve your digital certificate

Each one of the first two steps involves submission of details to the ROS site and waiting for a letter from Revenue with a code or password that must be used to get to the next step, so there can be a considerable amount of time involved in completing the whole process before you can actually use the service.

“For your own security”, ROS requires 2-factor authentication to enter the site as well as to submit any particular tax form. The authentication is based on the digital certificate you retrieve from ROS as well as a password you create for the certificate. This password can be subsequently changed after you initially provide it. Since you need to store this certificate locally, ROS decided that the best way to implement the authentication mechanism was using both a Java Applet and a custom package, KCrypto (not to be confused with the KDE package by the same name), that includes software from Baltimore to handle the certificate operations.

Problems arise when you aren’t running Windows or MacOS, and, according to the system requirements page even though you can execute the pre-requisite applet, Unix or Linux isn’t yet a supported platform—even though it is promised “soon”. The root of the issue is really two-fold: first, on an operating system where you just can’t throw files higgledy-piggledy anywhere you like, the applet installer doesn’t have the permissions to write the files, and the running applet doesn’t appear to make any attempt to put the certificates anywhere other than “C:\ROS”. Even if MacOS X is a supported platform, from the comments on a blog post from Tom Raftery in 2004, people are still having trouble using ROS under MacOS X in September 2006. Other people have tried using Wine to get the ROS applet to work under Linux, but they didn’t have much luck either.

What’s that? “Java is platform independent; you know, ‘write once, run anywhere’,” you say? “But, it’s a Web application,” you say?

Not quite.

Even with all those obstacles, it is possible to get it working natively under Linux if you have a little patience and can tolerate a few display glitches.

Making ROS work under Linux

NOTE: ROS does not officially support Linux, so these instructions are provided “as is” and do not imply any sort of warranty or liability by me if you have problems with your taxes if you try and use Linux to access ROS. Use at your own risk.

I’m using Firefox 2 under Linux with the JRE 1.4 plug-in. Everything works up until you attempt to install the applet as part of Step #3 for Retrieval of your Certificate. I managed to make everything work, but I had to re-trace my steps back to retrieval of the certificate because once the required libraries are installed, it kept asking me to log in. I hadn’t gotten the certificate yet, so the log in drop-down for certificates was empty.

When attempting to download and install the supporting applet, you will first encounter an error. Using information from the Java Console, you can identify exactly what the issue is. Because I wasn’t clever enough to save them, I can’t tell you exactly what they were, but you will see lots of “permission denied” errors at various points during the install. To display the Java Plug-in Console, run $JAVA_HOME/jre/bin/ControlPanel and set it to “always display” before you start trying to install the ROS applet.

At some point, you will get a message about downloading kcrypto-sun-1.4.jar. You will need to manually download this file from and copy it to: $JAVA_HOME/jre/lib/ext/.

This is the key step. Once you have done this, the applet installation will work and you should be able to start at the ROS “Home Page” and start the process of retrieving your certificate again.


Once the installation issue is solved, you will have to deal with a set of applets built using absolute positioning with the Windows control metrics. This means that there are overlaps between the controls and the height of some of the text fields will prevent you from seeing what you’re typing. Most of these aren’t anything but annoying.

As previously mentioned, your certificates will be stored in $HOME/C:/ROS/, which, while annoying, seems to work.

If I notice anything else as I use the service more, I’ll update this article with the new information. Otherwise, if you’re determined to use Linux for running your business in Ireland, I hope this article helps you get around some lazy coding on the part of the ROS team.

It is quite clear that ROS was intended first and foremost as a Windows service. Having written real cross-platform Java applications using JFC in the past, it isn’t generally too hard to do it, if that’s what you’re starting out to do and you have some understanding of the target platforms. Bolting it on later nearly always results in a number of places where people make assumptions about where things live (having a drive C: on something which isn’t Windows, for example) that could’ve been avoided with a bit more planning at the beginning.

Fixed the following errors:

  • It is nearly impossible to find the download URL for the kcrypto jar if you miss it the first time. I thought it was easier than it was, but, on trying to do it again, it should’ve been part of the post.
  • I erroneously stated the extension directory was $JAVA_HOME/jre/lib/extensions rather than $JAVA_HOME/jre/lib/ext.


  1. Insights » ROS KO’s 64-bit Linux said,

    May 15, 2008 at 4:45 pm

    […] Previously, I’d figured out a way to convince ROS to work under Linux. What I didn’t realize at the time, was that it only works on 32-bit Linux and not 64-bit. There are probably a couple of reasons for this sorry state of affairs. First, Sun isn’t going to provide a 64-bit Java plug-in until the release of Java 7 (or 1.7 if you’re one of us old-timers that’s worked with it since the beginning). Second, I’d say that the core “kcrypto” part of the way ROS works hasn’t been revisited in a while (since it’s built on Baltimore’s crypto stuff, and they haven’t been in this space for about 5 years). […]

  2. Richard Long said,

    September 20, 2008 at 7:03 pm

    I had the same problem with OS X in July 2005.

    You need to go to the ROS site as an OS X user with “administrator” privileges, or else you get an error relating to KCrypto.jar. All you have to do is go to the web site as an administrator and then you will have sufficient rights to be able to write kcrypto.jar to /Library/Java/Extensions. At this point you can then access the ROS site with a user with “standard” rights.

  3. damian said,

    November 16, 2009 at 2:42 pm

    Kcrypto isn’t on the ROS site anymore, where could I get it?

  4. AST said,

    November 16, 2009 at 3:06 pm

    Hi Damian,

    You don’t need it anymore. Once your account has been migrated to the new ROS system, the keys are converted and you can use the built-in Java plugin in 64-bit or 32-bit Linux. I’m assuming that this means it works as expected using OSX these days too.

    If you still have trouble, I’ll try and help, but I’ll need more information about your system configuration. You can always reach me on twitter at @atownley and we can see if that will help.



  5. damian said,

    November 16, 2009 at 6:17 pm

    I accessed the new ROS system a couple of months ago and everything worked fine, however I’m now using a new system with an old backup cert as I can’t access my old computer. So I think I still need kcrypto to access ROS. Do you have a link I could use?

  6. AST said,

    November 20, 2009 at 8:36 am

    Hi Damian,

    Sorry for the follow-up delay. I think there’s no good way to do that except to trigger the certificate upgrade again directly. I know I had trouble doing it (”some certificates do that”), so the guy on the support side of things gave me a different URL to try. Turned out that it was the certificate upgrade URL, but I don’t have a reference to it right now.

    I’m not sure that they still support access with the old kcrypto stuff. However, if you still want to try it, here’s the old one.

    Hope this helps. I know even with access from Linux, the core ROS is still pretty dire. At least it’s really cross-platform now! :)

  7. Marcin Owsiany said,

    June 29, 2013 at 11:36 am

    I just managed to login into ROS on a new computer (Debian GNU/Linux 7.0 wheezy amd64, with Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130515 Firefox/17.0 Iceweasel/17.0.6) using a cert I had downloaded a few years ago.

    The key piece of the puzzle this time was to keep the certs in $HOME/ROS/RosCerts
    Trying to keep them elsewhere and pointing the applet at that location just DOES NOT WORK. The applet throws a NullPointerException and that’s it.

    Note that even after the login page finds the cert and logs you in fine, the “ROS System Compatibility check” at will keep saying that the “ROS Certificate Directory” is “unknown” and that it does not exist, and therefore is not writable. This is probably because the applet does not have the permission to retrieve the value of the ‘user home directory’ system property, judging by the following stack trace:

    Exception in thread “AWT-EventQueue-3″ java.lang.NullPointerException
    at ie.revenue.ros.helpcentre.applet.SystemCheck.decode(
    at ie.revenue.ros.helpcentre.applet.SystemCheck$1$
    at java.awt.event.InvocationEvent.dispatch(
    at java.awt.EventQueue.dispatchEventImpl(
    at java.awt.EventQueue.access$200(
    at java.awt.EventQueue$
    at java.awt.EventQueue$
    at Method)
    at java.awt.EventQueue.dispatchEvent(
    at java.awt.EventDispatchThread.pumpOneEventForFilters(
    at java.awt.EventDispatchThread.pumpEventsForFilter(
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(
    at java.awt.EventDispatchThread.pumpEvents(
    at java.awt.EventDispatchThread.pumpEvents(
    Error getting users directory: access denied (”java.util.PropertyPermission” “user.home” “read”)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at sun.applet.PluginAppletSecurityContext$
    at Method)
    at sun.applet.PluginAppletSecurityContext.handleMessage(
    at sun.applet.AppletSecurityContextManager.handleMessage(
    at sun.applet.PluginStreamHandler.handleMessage(
    Caused by: access denied (”java.util.PropertyPermission” “user.home” “read”)
    Error on Java side: LiveConnectPermissionNeeded access denied (”java.util.PropertyPermission” “user.home” “read”)
    at java.lang.SecurityManager.checkPermission(
    at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(
    at java.lang.SecurityManager.checkPropertyAccess(
    at java.lang.System.getProperty(
    at ie.revenue.ros.helpcentre.applet.SystemCheck.getDefaultRosCertDirectory(
    at ie.revenue.ros.helpcentre.applet.SystemCheck.getHTMLSafeCertDirectory(
    … 10 more

    The incompetence of people who write this software is further shown by this hilarious piece of evidence:
    on my old laptop, that I registered for ROS on, the certificates were stored in a non-standard location, and yet it worked fine. When I went to the “ROS system check” page yesterday on that laptop, the “ROS Certificate Directory” was shown as a long string of hexadecimal numbers. Turns out that when I decoded it by treating each number as an ascii character code, it did translate to the path I had selected.

Leave a Comment