Supermicro IPMI JAVA - mTLS Problem as of 17th May 2026

[VMman]

Is anyone else facing a problem with Supermicro JAVA no longer working since yesterday?

I know that HTML is preferred but I have some older servers where i'm stuck using JAVA.

I suspect the TLS has expired on the X10/X11 generation of IPMI which is causing JAVA to fail to open connections.
Other than waiting for SM to release a patch (not hopeful) what can be done to work around?

Thanks!

 

[gregsachs]

GitHub - solarkennedy/ipmi-kvm-docker: A Dockerfile to make it easy to use the ipmi kvm on hosts

A Dockerfile to make it easy to use the ipmi kvm on hosts - solarkennedy/ipmi-kvm-docker

github.com

Or I have an Avocent MergePoint Unity KVM for sale!

 

[TrevorH]

Stop any time sync processes, manually set the date back to one that works, connect. Once connected, see if there are any cert options in there that can be used to renew the installed one or manually upload your own.

 

[cesmith9999]

I have been having thnsi headache for a while. I use IPMIView to do remote in to my SM MB.

Chris

 

[codyjd1]

Same issue on X10 and X11 boards. Both IPMIView on IOS and Windows no longer can connect with JAVA.

 

[VMman]

Same issue on X10 and X11 boards. Both IPMIView on IOS and Windows no longer can connect with JAVA.

Current work around is to change the date on the PC and the BMC to something before the 17th.

 

[cesmith9999]

Is this a cert expiring issue?

Chris

 

[VMman]

Is this a cert expiring issue?

Chris

Appears to be yes

 

[TrevorH]

I googled and it does appear you can upload your own SSL certs. "in the Configuration > Network > SSL Certificates there's a form to upload the freshly generated certificates.". So once you gain access, you should be able to upload your own SSL cert that is not expired. Generation of said cert is left to you and Google.

 

[kapone]

I just disable https if possible, on any such interfaces. I mean…they live on an OOB vlan that is completely closed off and firewalled, with a single jump box as ingress.

what could go wrong…

 

[timke]

HTML5 and port 5900 were fine, but Java kept looping Retry 1-10. Flashing the firmware up from v1.74.14 to v1.74.19 (with Preserve Configuration checked) fixed it instantly.

 

[mattventura]

HTML5 and port 5900 were fine, but Java kept looping Retry 1-10. Flashing the firmware up from v1.74.14 to v1.74.19 (with Preserve Configuration checked) fixed it instantly.

Sadly, it looks like 1.74.13 is the most recent for my X11 boards. I'll look into generating custom certs.

 

[azbest_hu]

It seems the client cert for stunnel is expired that provided by the X9 ipmi. But also, even the latest IpmiView 2.24 util has the same expired cert included, so that is also failing. The embedded stunnel.conf has the setting for check certs strictly. IpmiView includs this setting in their generated file also. Not sure, how can this be fixed.

 

[Fritz]

I just disable https if possible, on any such interfaces. I mean…they live on an OOB vlan that is completely closed off and firewalled, with a single jump box as ingress.

what could go wrong…

I have a couple of X12STL-IF that won't allow me to disable https, it's grayed out.

 

[twin_savage]

It's possible I'm entirely off the mark here, but wouldn't just adding a java site exception remedy the problem?

I've got an x11 deployment coming up next year and I'm going to hit this issue.

 

[azbest_hu]

It's possible I'm entirely off the mark here, but wouldn't just adding a java site exception remedy the problem?

I've got an x11 deployment coming up next year and I'm going to hit this issue.

Unfortunately, no.

I tried this tool with my X9 mainboard

GitHub - MisterCalvin/supermicro-java-ikvm: A container for connecting to Supermicro Java based iKVM viewers via a web browser

A container for connecting to Supermicro Java based iKVM viewers via a web browser - MisterCalvin/supermicro-java-ikvm

github.com

which prepares a linux environment in a docker container for the client.
I tried to modify the build/rootfs/etc/cont-init.d/50-setup-ikvm.sh script to change verify = 3 into verify = 0.
But this is only helping client side.

Added some lines to the end of that script:

apt update
apt install zip -y
mkdir -p /tmp/stunnel/res/
unzip -j $JAR res/linux/stunnel.conf -d /tmp/stunnel/res/linux/
sed -i 's/^verify = 3$/verify = 0/' /tmp/stunnel/res/linux/stunnel.conf
sed -i 's/^; output = stunnel\.log$/output = \/tmp\/stunnel\.log/' /tmp/stunnel/res/linux/stunnel.conf
unzip -j $JAR res/win/stunnel.conf -d /tmp/stunnel/res/win/
sed -i 's/^verify = 3$/verify = 0/' /tmp/stunnel/res/win/stunnel.conf
sed -i 's/^; output = stunnel\.log$/output = \/tmp\/stunnel\.log/' /tmp/stunnel/res/win/stunnel.conf
unzip -j $JAR res/mac/stunnel.conf -d /tmp/stunnel/res/mac/
sed -i 's/^verify = 3$/verify = 0/' /tmp/stunnel/res/mac/stunnel.conf
sed -i 's/^; output = stunnel\.log$/output = \/tmp\/stunnel\.log/' /tmp/stunnel/res/mac/stunnel.conf
cd /tmp/stunnel
zip -r $JAR .

So it changes the conf file, that is used by stunnel run by the iKVM jar.
In the log I saw client side ignored the expired cert, but the server side also has these expired certs. That is tunning inside the BMC. Replacing https cert is not affecting this. When I set the IPMI clock back before 17 of May, it started working.

Server side stunnel,conf has

[ikvm]
verify = 3
accept = :::5900
connect = :::63630
cert = /etc/stunnel/server.crt
key = /etc/stunnel/server.key
CAfile = /etc/stunnel/client.crt

Client side stunnel has

[ikvm]
client = yes
accept = 127.0.0.1:42017
connect = 192.168.8.162:5900
verify = 3
cert = /tmp/1779982740701/client.crt
key = /tmp/1779982740701/client.key
CAfile = /tmp/1779982740701/server.crt

We can edit the client side to have "verify = 3", but I don't know any way to edit the server side.
When I tried to use self signed cert on the client, I got "unknown CA" error fron the server.
I think, because these certs and settings are baked into the BMC firmware, we are not able to fix this by ourself.
At least the BMC clock have to be dialed back every time after BMC restart. That can be done from the IPMI web.

 

[RolloZ170]

maybe not disable, but change to one actual cert ?
there are some automation scripts at gh

 

[azbest_hu]

It is embedded in the BMC firmware. Maybe if it would be possible to ssh into the IPMI, but as far as I understand, that has been disabled long ago.

Other idea for the BMC clock:
We can put a http post call after the login into the script, to call config_datetime with an old date. So it can be automated.

get_launch_jnlp() {
    fail=1
    url="http://$KVM_HOST"
    temp=$(mktemp)
    if curl --fail -sk --cookie-jar "$temp" -XPOST "$url/cgi/login.cgi" \
          --data "name=$KVM_USER&pwd=$KVM_PASS&check=00" -o/dev/null; then
        launch_jnlp=$(curl --fail -sk --cookie "$temp" \
            --referer "$url/cgi/url_redirect.cgi?url_name=man_ikvm" \
            "$url/cgi/url_redirect.cgi?url_name=man_ikvm&url_type=jwsk")
            (curl --fail -sk --cookie "$temp" \
            --referer "$url/cgi/url_redirect.cgi?url_name=config_datetime" \
            -XPOST "$url/cgi/config_date_time.cgi" --data "timezone=0&dst_en=0&ntp=off&ntp_server_pri=localhost&ntp_server_2nd=127.0.0.1&year=2026&month=4&day=28&hour=12&min=01&sec=1")
           
        test $? -eq 0 && fail=
    fi
    #rm "$temp"
    test -z "$fail" && echo "$launch_jnlp"
}

The actual server clock is independent from the BMC, i think. So it should not affect much other stuff. The on-the-fly jar modification handles the cliend side.

Modded supermicro-java-ikvm docker (line endings should be unix style in the script files)

GitHub - azbesthu/supermicro-java-ikvm: A container for connecting to Supermicro Java based iKVM viewers via a web browser

A container for connecting to Supermicro Java based iKVM viewers via a web browser - azbesthu/supermicro-java-ikvm

github.com

I don't plan to maintain it. It has other forks also, not sure what other useful changes are there in other forks.

 

[RolloZ170]

It is embedded in the BMC firmware.

sorry, i thought it worked that way:

source

 

[azbest_hu]

That upload is for HTTPS cert

iKVM uses different port, it is 5900. Those certs are embedded in the ipmi rom filesystem and in the JAR file that is downloaded by the jnlp client. Also the same certs are included in ipmiview util. Same expired certs.

I uploaded a freshly generated self signed cert with the web form, but still getting the old cert on iKVM port.

Still getting the original cert on 5900: "notAfter=May 17 09:44:10 2026 GMT"

openssl s_client -showcerts  -connect 192.168.x.x:5900
CONNECTED(00000168)
Can't use SSL_get_servername
depth=0 C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI, emailAddress = Email
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI, emailAddress = Email
verify error:num=10:certificate has expired
notAfter=May 17 09:44:10 2026 GMT
verify return:1
depth=0 C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI, emailAddress = Email
notAfter=May 17 09:44:10 2026 GMT
verify return:1

My self signed cert on https port: "NotAfter: May 25 15:14:40 2036 GMT"

openssl s_client -showcerts -connect 192.168.x.x:443
CONNECTED(000000B4)
Can't use SSL_get_servername
depth=0 C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI
   i:C = US, ST = California, L = San Jose, O = Super Micro Computer, OU = Software, CN = IPMI
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 28 15:14:40 2026 GMT; NotAfter: May 25 15:14:40 2036 GMT
...