supermicro X11 ipmi ssl and java kvm annoyances

gzorn

Member
Jan 10, 2017
76
14
8
Hi all,
The Supermicro IPMI is a constant source of both conveniences and inconveniences.
Here are 2 problems that I've encountered lately, including workarounds. If you've got a better fix, please share.
The board in question is an X11 ssi-ln4f, with BMC firmware 1.48.

1. Java web start IKVM failure:
If I access IPMI through a DNS name, for example: ipmi.admin.mynet, and try to start up the java KVM then the jnlp file created by IPMI doesn't get the server IP address properly populated. There's an argument tag set in the jnlp file that's left blank.

Workaround #1: If you edit the downloaded jnlp file and add the server address to the appropriate argument tag set, then it will work in java web start

Workaround #2: Use the HTML5 iKVM (but you cannot mount virtual drives from this - handy for OS install).

Workaround #3: Access your IPMI using the numeric address. Then java web start KVM works for me.
Any other ideas?

2. SSL cert with an intermediate certificate.
I'm using my pfsense router to provide certs for all of my internal servers. I've got the master certificate self-signed and used it to sign an intermediate certificate. I imported the master certificate to my laptop's trusted list. I've created a server cert for the IPMI function on the board. First, make sure to use the defaults from pfsense GUI - when I used stronger cryptography, I think the IPMI choked on it.

Problem: If I sign it with my intermediate certificate, my web browser (Chrome) won't show the server as trusted. This happened even if I export the full chain of trust in the server cert file and upload that to the IPMI board (I used openssl to convert the p12 file to a text cert file with the intermediate cert in there).

Workaround: If I sign it with the master certificate, it does show as trusted.
I thought it was best practices to have an intermediate cert and use that for all server sign-offs. Or am I doing certificates wrong?
 
  • Like
Reactions: nthu9280

Blinky 42

Active Member
Aug 6, 2015
615
230
43
46
PA, USA
You can mount virtual media using html5 console, it just isn't integrated into the window the same way to mount local media.
On the ipmi web interface -> virtual media menu -> floppy or CD ROM images.

Somewhat annoyingly it is CIFS / SMB for the mount but it does indeed work even mounting the image over the internet at large.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,395
506
113
Problem: If I sign it with my intermediate certificate, my web browser (Chrome) won't show the server as trusted. This happened even if I export the full chain of trust in the server cert file and upload that to the IPMI board (I used openssl to convert the p12 file to a text cert file with the intermediate cert in there).

Workaround: If I sign it with the master certificate, it does show as trusted.
I thought it was best practices to have an intermediate cert and use that for all server sign-offs. Or am I doing certificates wrong?
You need to export the intermediate CA cert and add that to your browser's CA store as well. IIRC chrome on windows uses the windows cert store, so import it into the Intermediate Certification Authorities store.
 

gzorn

Member
Jan 10, 2017
76
14
8
Thanks for the comments, all.
@nthu9280 , at one point I did use IPMIview on linux, but I only got it working for image mounting. It didn't work for KVM, sadly.

@Blinky 42 - Yeah, I saw that. For some reason, I wasn't able to make that work. No idea why.

@MiniKnight - For my board, 1.48 is the latest firmware for the BMC. The 2.2 is the system bios version (which is also latest).
 

Blinky 42

Active Member
Aug 6, 2015
615
230
43
46
PA, USA
@Blinky 42 - Yeah, I saw that. For some reason, I wasn't able to make that work. No idea why.
I was fighting with it for a while to no avail using anonymous / guest access on a samba server, but when I switched it over to use a username & password it worked like a champ.
 

sean

Member
Sep 26, 2013
66
33
18
CT
You need to export the intermediate CA cert and add that to your browser's CA store as well. IIRC chrome on windows uses the windows cert store, so import it into the Intermediate Certification Authorities store.
I can't comment on the Windows certificate stores, but it's common for the server to send its certificate and the intermediate. This site does that. First is the certificate for forums.servethehome.com and then Let's Encrypt's X3 intermediate.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,395
506
113
I can't comment on the Windows certificate stores, but it's common for the server to send its certificate and the intermediate. This site does that. First is the certificate for forums.servethehome.com and then Let's Encrypt's X3 intermediate.
If by this you mean sending the cert chain, then yes - but the client will still need to trust every member in the chain, so if you're using an internal root CA and an intermediate CA, you'll need to have both listed as trusted cert authorities. I guess you could "pretend" and just say that your intermediate CA is actually a root CA but this is pretty pointless, better to just install the CAs properly - it's a doddle to do via GPO in windows and by dumping the PEMs into /usr/local/share/ca-certificates on debian (can't remember how RHEL does it).

<derail>
Personally, I only bother with running a root CA at home; there's only really a point in segregating them if you're going to keep your root CA turned off, frozen in carbonite and airgapped at the bottom of a locked filing cabinet with the requisite Beware of the Leopard sign and only spin it up when you need a new (or a renewed) intermediate CA. As I'm only one logical business unit with only a couple of boxes (none of which are airgapped) it's a good deal simpler to run directly from my (reasonably well secured) root CA; but as per the comments above, best practice for business is of course to run root + intermediates.
</derail>
 

jlagermann

New Member
Mar 23, 2020
1
1
1
but the client will still need to trust every member in the chain, so if you're using an internal root CA and an intermediate CA, you'll need to have both listed as trusted cert authorities.
That's absolutely not true, the client should ONLY need to trust the root certificate. That's the entire point of having a certificate chain. A client will automatically trust the Intermediate Certificate if it trusts the root, or the intermediate that signed it. The problem is, the client does not have any information about the intermediate if the server does not present it with the "end entity" certificate. If the server properly presents the entire chain with it's end entity cert, and the client trusts the root, the entire chain will be trusted.

As a work-around, you can directly trust the intermediate cert, but that is an extra step you should not have to do if the server is properly configured (or works as it should). In some cases, you can combine the chain with the cert before you upload it to the server, but that does not always work.
 
  • Like
Reactions: Pegasi

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,395
506
113
That's absolutely not true, the client should ONLY need to trust the root certificate. That's the entire point of having a certificate chain.
Sorry, bad wording on my part. Rather than saying they should all be trusted as CAs I of course meant trusted as either CAs or intermediates (but you can trust the intermediate as if it were a CA as a workaround).
 

Pegasi

New Member
Mar 27, 2020
2
0
1
Sorry, bad wording on my part. Rather than saying they should all be trusted as CAs I of course meant trusted as either CAs or intermediates (but you can trust the intermediate as if it were a CA as a workaround).
That's still not true, and is the point they're making. The only certificate that the client need trust explicitly is the root CA.

Then, when a server presents a full certificate chain, the intermediate shows as being signed by the root, which the client trust, therefore the intermediate is trusted even though it's not been added to the client (be it browser, OS, whatever) explicitly. The server cert is then trusted by the same logic, because it's signed by the intermediate.

As jlagermann says, that's the whole purpose of certificate chains. You distribute the root, but intermediates can be used and swapped out as necessary as long as servers are presenting full certificate chains. If you needed to trust both the root and and intermediates explicitly, whats the point of a tiered CA?

FWIW: I've run up against this same thing. I have a certificate with server -> intermediate -> root details, but IPMI only presents the server cert. This format is pretty common, and things which don't use it often give you an option to upload the CA information separately.

Are intermediate CAs just not supported in this way?
 
Last edited:

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,395
506
113
It's been a while since I tried it in anger, but if you delete or disable the intermediate cert in your cert store then the chain breaks and you lose connectivity. Intermediates don't get automatically trusted just because they're signed by a trusted root CA.

There's not really any point in having intermediates otherwise. The purpose of the chain concept is that you have an unbroken string of trust from cert to root, so if you delete or revoke any of the intermediate certs the chain will break and you'll be unable to verify. In the case here where IPMI presents a cert A trusted by intermediate B, which is trusted by CA C. if you're missing intermediate B for whatever reason the verify will fail since there's no longer a chain to the CA.

TTBOMK there are some methods present in windows that will automatically install certain intermediate certs (see an example here) but I deal with a lot of machines with no internet access where all certs have to be explicitly installed and can tell you that if you don't import the intermediate cert, verify won't work.

Don't think I've ever seen any of the linux machines do the same thing but most of the work I do there is manually configuring java keystores with explicit certificates rather than using the system cert store.

My home CA doesn't have an intermediate though so I've not tested the SM IPMI behaviour with intermediates, but I'd be very surprised if they didn't work.
 

Pegasi

New Member
Mar 27, 2020
2
0
1
It's been a while since I tried it in anger, but if you delete or disable the intermediate cert in your cert store then the chain breaks and you lose connectivity.
This isn't true, or at least isn't true with a correctly configured CA. Look at your trusted CA store on your machine, how many intermediates do you notice in there versus how many sites and CAs use (many different) intermediates?

Intermediates don't get automatically trusted just because they're signed by a trusted root CA.
Yes they do, again that's kind of the point of a certificate chain. As an example, I've been on a bit of a cert spree with my home CA recently, and every other device or application I've worked with works like this. The only cert I've distributed to clients is the root, the intermediate is not explicitly trusted on any machine in my lab. Yet, because servers are presenting chains, the certificates work just fine.

There's not really any point in having intermediates otherwise. The purpose of the chain concept is that you have an unbroken string of trust from cert to root, so if you delete or revoke any of the intermediate certs the chain will break and you'll be unable to verify. In the case here where IPMI presents a cert A trusted by intermediate B, which is trusted by CA C. if you're missing intermediate B for whatever reason the verify will fail since there's no longer a chain to the CA.
That doesn't really make sense, as what would be the purpose of intermediates in that case? There'd be no advantage to using one, and we'd just have directly root-signed certs for everything.

TTBOMK there are some methods present in windows that will automatically install certain intermediate certs (see an example here) but I deal with a lot of machines with no internet access where all certs have to be explicitly installed and can tell you that if you don't import the intermediate cert, verify won't work.
I can't speak to any specific situations you've deal with, but I also deal with this as a reasonably significant part of my job, and can tell you that it does work, and it's standard practice for internet services.

EDIT: It's how this site is set up, for example. The DST Root CA X3 certificate is installed in my OS' trusted root store. The Let's Encrypt Authority X3 intermediate certificate isn't installed anywhere in my OS or browsers, but is trusted because it's signed by the DTS Root CA X3. The server certificate, forums.servethehome.com, is then trusted, because it is in turn signed by the Let's Encrypt intermediate.

The server needs all 3 certs installed, so it can present a full chain to clients. But the client only needs the root CA installed as trusted, and from that can verify the chain. If that weren't the case, I would receive a certificate warning for this page, as my clients do not have the intermediate CA installed and marked as trusted.
 
Last edited: