Jenkins and HTTPS

[Gaiseric Vandal]

I am setting up jenkins on an CentOS 8 machine.  Currently have one running under Ubuntu 16.

On the new machine, I am unable to get HTTPS working, even tho the config seems the same as the other machine.

My partial config file is

            # cat /etc/sysconfig/jenkins
            #
            JENKINS_HOME="/var/lib/jenkins"
            JENKINS_JAVA_CMD=""
            JENKINS_USER="jenkins"
            #JENKINS_INSTALL_SKIP_CHOWN="false"
            JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
            JENKINS_PORT="8080"
            JENKINS_LISTEN_ADDRESS=""
            JENKINS_HTTPS_PORT="443"
            JENKINS_HTTPS_KEYSTORE="/etc/jenkins/jenkins.jks"
            JENKINS_HTTPS_KEYSTORE_PASSWORD="xxxxxxx"
            JENKINS_HTTPS_LISTEN_ADDRESS="0.0.0.0"
            JENKINS_HTTP2_PORT=""
            JENKINS_HTTP2_LISTEN_ADDRESS=""
            JENKINS_DEBUG_LEVEL="5"
            JENKINS_ENABLE_ACCESS_LOG="no"
            JENKINS_HANDLER_MAX="100"

            JENKINS_HANDLER_IDLE="20"
            JENKINS_EXTRA_LIB_FOLDER=""
            JENKINS_ARGS=""
            #

I am quite certain I have the key store correct

I set up with

    keytool -genkey -alias servername.mydomain.com   -keyalg RSA -keystore /etc/jenkins/jenkins.jks -keysize 2048

Then generated a CSR, had it signed by our internal CA.

Also imported the certificates for the CA's.

I have the following errors

            $ cat /var/log/jenkins/jenkins.log

            Running from: /usr/lib/jenkins/jenkins.war

            Exception in thread "Jenkins initialization thread" java.lang.NoClassDefFoundError: hudson/util/HudsonFailedToLoad

                    at hudson.WebAppMain$3.run(WebAppMain.java:276)

            Caused by: java.lang.ClassNotFoundException: hudson.util.HudsonFailedToLoad

                    at java.net.URLClassLoader.findClass(Unknown Source)

                   at java.lang.ClassLoader.loadClass(Unknown Source)

                    at java.lang.ClassLoader.loadClass(Unknown Source)

                    at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:543)

                    at java.lang.ClassLoader.loadClass(Unknown Source)

                    ... 1 more

            java.io.IOException: Failed to start Jetty

                    at winstone.Launcher.<init>(Launcher.java:184)

                    at winstone.Launcher.main(Launcher.java:355)

                    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

                    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

                    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

                    at java.lang.reflect.Method.invoke(Unknown Source)

                    at Main._main(Main.java:375)

                    at Main.main(Main.java:151)

            Caused by: java.net.SocketException: Permission denied

                    at sun.nio.ch.Net.bind0(Native Method)

                    at sun.nio.ch.Net.bind(Unknown Source)

                    at sun.nio.ch.Net.bind(Unknown Source)

                    at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)

                    at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)

                    at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:342)

                    at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)

                    at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)

                    at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)

                    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)

                    at org.eclipse.jetty.server.Server.doStart(Server.java:385)

                    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)

                    at winstone.Launcher.<init>(Launcher.java:182)

        ... 7 more

$

I also tried extracting the key and cert  and tried the following

         /etc/alternatives/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --httpPort=8080 --httpsPort=443   --httpsListenAddress=0.0.0.0 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20  --httpsCertificate=/etc/jenkins/jenkins.cer --httpsPrivateKey=/etc/jenkins/jenkins.key

Same errors.

I disabled selinux.  Did not help.

Tried linking /etc/alternative/java (default in the search path ) to Oracle 8 Java, OpenJDK8 and OpenJDK11.  No luck.

Appreciate any advice.

Thanks

[Gianluca]

Trying to guess:

" java.net.SocketException: Permission denied" 

this smells of Java not running with enough privileges to open ports below 1024

Usually on Linux systems only root can open such ports.

[Mark Waite]

On Fri, Jul 24, 2020 at 9:12 AM Gianluca <gma...@gmail.com> wrote:

Trying to guess:

" java.net.SocketException: Permission denied" 

this smells of Java not running with enough privileges to open ports below 1024

Usually on Linux systems only root can open such ports.

As further help with that, you might try the guidance for "Running Jenkins behind iptables" .  That section of the reverse proxy configuration document uses the Linux kernel's iptables facility to route traffic from the privileged port (80 or 443) to an unprivileged port (usually 8080).  The document is only recently merged and we'd love to have feedback. corrections, and improvements to it.

Mark Waite

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3eb7bec5-af4e-4f6b-ad4b-ba069b9f0f4do%40googlegroups.com.

[Dirk Heinrichs]

Am Freitag, den 24.07.2020, 11:27 -0600 schrieb Mark Waite:

As further help with that, you might try the guidance for "Running Jenkins behind iptables" .  That section of the reverse proxy configuration document uses the Linux kernel's iptables facility to route traffic from the privileged port (80 or 443) to an unprivileged port (usually 8080).  The document is only recently merged and we'd love to have feedback. corrections, and improvements to it.

We used to use this method in our setups, too, but recently switched to using an Apache web server (NGinx would also work) as reverse proxy in front of any, esp. Java based, web service we're running. The reason for this is that all the SSL setup is far easier there and also unified accross all the services, regardless which application server they're based on (Tomcat, Jetty, ...).

HTH...

Dirk

-- 

Dirk Heinrichs

Senior Systems Engineer, Delivery Pipeline

OpenText ™ Discovery | Recommind

Phone: +49 2226 15966 18

Email: dhei...@opentext.com

Website: www.recommind.de

Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach

Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan, Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.

[Gaiseric Vandal]

Changed port to 8443.  That seems to have fixed it.

Thanks

[Mansom, Ewout van]