0

Jenkins plugin accessing REST server, apparent certificate problem?

I'm going to kick myself when I see the answer, I'm sure...

I'm trying to get a Jenkins plugin running which wants to issue an https: request to a Jira server. (No, the existing Jira plugins don't do what I need; checked that.) I'm using Atlassian's wrapper classes for the Jira REST API to avoid having to reimplement REST yet again.

Our Jenkins is running as a Linux Service, in case that matters at all.

Problem: Our Jira server's certificate is not being accepted, resulting in 401 "Unauthorized" responses. And simply adding the certificate to the Java "cacerts" file and stopping/restarting the Jenkins service isn't overcoming that.

I was able to resolve this on my own machine by explicitly setting what I *thought* was Java's default:

JAVA_OPTS="-Djavax.net.ssl.keyStore=$JAVA_HOME/jre/lib/security/cacert"

But I've been having trouble persuading our "official" Jenkins server to admit the new certificate is acceptable.

The API, alas, doesn't cope well with non-JSON responses such as the 401 page, but the response appears to be (skipping the boilerplate scripts and links):

<html>

<head>
    <title>Unauthorized (401)</title>
    <meta name="application-name" content="JIRA" data-name="jira" data-version="7.3.6">
</head>
<body id="jira" class="aui-layout aui-style-default page-type-message"  data-version="7.3.6" >
    <div class="aui-page-panel"><div class="aui-page-panel-inner">
            <section class="aui-page-panel-content">
                    <header class="aui-page-header"><div class="aui-page-header-inner">
                            <div class="aui-page-header-main">
                                    <h1>Unauthorized (401)</h1>
                                </div><!-- .aui-page-header-main -->
                        </div><!-- .aui-page-header-inner --></header><!-- .aui-page-header -->
                    <div class="aui-message aui-message-warning warning">
                            <p>Encountered a <code>&quot;401 - Unauthorized&quot;</code> error while loading this page.</p>
                            <p><a href="/secure/MyJiraHome.jspa">Go to JIRA home</a></p>
                        </div>
                </section><!-- .aui-page-panel-content -->
        </div><!-- .aui-page-panel-inner --></div><!-- .aui-page-panel -->
</body>
</html>

Yes, I can successfully SSLPoke port 443 on the Jira server from a shell step in a Jenkins job run on the production server.  No, the Jira server isn't running on an unusual port itself.

As I said, the same plugin, with the same user parameters and posting to the same Jira server, is running fine on a Jenkins server on my own machine when launched with "mvn hpi:run". (I haven't yet tried dropping it into my normally running Jenkins service; should do that...)


I've been running myself ragged for a few days trying to figure out what I'm doing wrong. Tried everything I've found on the Internet that looked likely to help. I'm sure it's something obvious, but darned if I can find it.

Any advice on other diagnostics to try would be most welcome.


 

 




5 comments

  • 0
    Avatar
    Joe Kesselman

    Just tried installing the cert into my Docker Jenkins, on my local machine, by inserting it into  $JAVA_HOME/jre/lib/security/cacerts just as I did on the production machine. The Docker version runs fine and contacts the remote Jira server happily.

    The production server still gets 401.

    I'm very confused.

     

  • 0
    Avatar
    Joe Kesselman

    Never mind. Kicking myself in the head -- We have too many userIDs and passwords running around, and Jira expects a particular combination that I find counter-intuitive.

    Ouch. User error.

  • 0
    Avatar
    Denys Digtiar

    It looks like rubberducking helps indeed :)

  • 0
    Avatar
    Joe Kesselman

    Yep.

    Though it still appears that Jira may need the Java option, to be explicitly told where to load the cacerts file from. Haven't seen that with other Java apps, so I'm still partly confused.

  • 0
    Avatar
    Denys Digtiar

    Yes, if bundled trust store doesn't include the required certificates it can be overridden by specifying the `javax.net.ssl.trustStore` system properties. We have an SSL Certificates Troubleshooting for such case.

    Some Linux distros have the infrastructure to update both system and JVM cacerts together, e.g. https://packages.debian.org/jessie/ca-certificates-java

Please sign in to leave a comment.