jenkins plugin throws SSLHandshakeException/CertificateException when attempting to retrieve file located on remote computer. how to fix?

2,227 views
Skip to first unread message

John Smith

unread,
Jul 25, 2013, 10:43:56 AM7/25/13
to jenkin...@googlegroups.com
I am working on a Jenkins plugin that implements a Post-Build action that retrieves files in the workspace and uploads them to a remote system using an https connection. It works fine when the files that need to be uploaded are located on the same machine as the Jenkins server, but one of the persons who recently used the plugin reports that the following stacktrace was printed on the console's output window when the plugin attempted to upload files located on a remote subversion server:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <name-of-server> found.
                at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
                at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1697)
                at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:258)
                at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:252)
                at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1165

That said, the following snippet shows the essence of what my code is doing:


    @Override
    public boolean perform(AbstractBuild<?, ?> build, Launcher launcher, BuildListener listener) throws IOException, InterruptedException
    {
        listener.getLogger().println("retrieving file list"); //this was printed
 
        ArrayList<String> list = new ArrayList<String>();
        for (FilePath filePath : build.getWorkspace().list())
        {
            list.add(filePath.act(new FilePath.FileCallable<String>()
            {
                public String invoke(File f, VirtualChannel channel) throws IOException, InterruptedException
                {
                    return f.getPath();
                }
            }));
        }

        listener.getLogger().println("uploading files"); // this was printed
 
        try
        {
            uploadFiles(list.toArray(new String[0]));//uploads files using java.net.URLConnection
        }
        catch (Throwable e)
        {
            listener.getLogger().println("Unable to upload files: " + e.getClass().toString());
            return false;
        }

        return true;
    }

Given that the last message that was printed before the stacktrace was printed was "uploading files", I assume this means that the plugin was able to establish a connection with the subversion server when it attempted to retrieve the filepaths of the remote files, but failed to re-establish the connection when it attempted to upload the remote files using java.net.URLConnection. Interestingly, the uploadFiles() method does not print any stacktrace in the event of an exception - it just throws the exceptions and lets the calling code handle them. Also notice that the call to this method is surrounded by a try-catch statement, which I would have expected to catch and handle any errors or exceptions related to files that could not be uploaded (it seems like the stacktrace that was printed to the console output window was not printed by code in the perform() or uploadFiles() method).

With that in mind,

Can someone please help me understand whether this SSL Exception was caused by something that my plugin did wrong or by a Jenkins/Subversion configuration error?

If the problem is the way I am trying to upload remote files (FilePath -> String -> File -> InputStream -> OutputStream), would it help if I skip a few steps and grab the file streams from the FilePath objects and write them directly to the URLConnection's OutputStream?

Finally, given that my code did not catch the SSL Exception, is it just a matter of making sure that any exceptions thrown by FileCallable's invoke() method are handled inside that method? (I was under the impression that those exceptions would have been propagated back to the calling code.)

Kohsuke Kawaguchi

unread,
Jul 25, 2013, 2:25:16 PM7/25/13
to jenkin...@googlegroups.com, John Smith

Every once in a while you come across a website that trips the big scary
warning about SSL certificates in the browser. This exception is the
Java equivalent of that.

Most likely the user has a problematic HTTPS setup. It looks like it's
serving the certificate that doesn't match the host name.

(In one of these days we'd convince the JDK people to make the SSL
handshaking error message understandable to non-experts!)

Bottom line, most likely an user error, not your coding problem. If it's
beyond the control of this user to fix the website, we provide an escape
hatch:

https://wiki.jenkins-ci.org/display/JENKINS/Skip+Certificate+Check+plugin

I'd just point the bug reporter to this, and close the issue as "not a
defect".
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>


--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
Reply all
Reply to author
Forward
0 new messages