Skip to main content

Displays won't connect over HTTPS: certificate problems

A display that is set to HTTPS and never shows up under Device > Unapproved is usually refusing the server's certificate, not failing to find the server. The browser on your PC may open the same address without complaint, because a display's player applies its own checks.

Symptoms​

  • The display is set to TLS (labelled SSL in older menus) and the HTTPS port, the server is reachable, and yet the display never registers.
  • The server's access log, if you keep one, shows no request at all from that display.
  • The same display connects at once when pointed at the HTTP port.
  • No error on the display's screen.

Recent firmware can validate the server certificate. When that check is on and fails, the connection fails silently, which is why this looks like a network fault. Work through the five causes below in order.

Why it happens, and the fix for each​

1. Untrusted or self-signed certificate on newer firmware​

A certificate the player cannot trace to an authority it trusts is rejected. Reported on 20.1010.x (MagicINFO 8) builds: QMB and QBB screens (Tizen 6.5) reached the server over HTTPS but never appeared under Unapproved, while the same screen worked against 21.1010.x. The reading is that newer players reject the older bundled self-signed certificate, and that newer builds ship a second-generation bundled certificate. A 21.1070 install has a MagicInfoCertG2.jks in C:\MagicInfo Premium\runtime\keystore\, which fits that picture.

To check on your build: compare your build number (how to find it) with the ones above, and see which keystore your HTTPS connector uses.

Fix: upgrade the server, or better, install a certificate from a public authority. The steps are in Change the MagicINFO HTTPS (TLS) Certificate. Choose your own keystore password and never keep an installer default.

2. The name does not match​

The certificate must name the host the display connects to. Public authorities rarely issue certificates for a bare IP address, so a display pointed at an IP usually meets a certificate that names something else. Fix: give the display a DNS name (magicinfo.example.com), issue the certificate for that name, and enter that name in the display's server settings.

3. Intermediate certificates are missing​

A keystore that holds only your own certificate can pass in a desktop browser, which may fetch the missing link itself, and fail on a display, which will not. Fix: build the keystore with the private key, your certificate and the full chain from the authority, then check it with keytool -list -v: a chain longer than 1 is what you want.

4. TLS version​

Reported, by player generation:

Player generationHighest TLS it speaks
S11.0
S2, S31.1
S4, S5, S61.2
S9 generation (Tizen 6.0 and later)1.3

A server limited to TLS 1.2 and 1.3, as it should be, cannot talk HTTPS to S1 to S3 players. Fix: keep those screens on HTTP inside a trusted network, or replace them. Do not re-enable TLS 1.0 or 1.1 on the server to bring them back: that weakens every connection on that port. Player generations are explained in MagicINFO player comparison.

warning

Never loosen the server's TLS settings to make an old screen connect. Move the screen, not the server.

5. Player trust is not browser trust​

Reported: the MagicINFO player and the display's built-in web browser keep separate lists of trusted authorities. If the browser on the screen opens your site, that does not prove the player trusts it. Test the player, not the browser.

Also check the display's date and time. A wrong clock makes a valid certificate look expired or not yet valid.

Fix: a safe order of work​

  1. From a PC, open https://magicinfo.example.com:7002/MagicInfo/openapi/auth?cmd=isMagicInfo with the exact name the display uses. You should get a short build number and no warning.
  2. Look at the certificate in the browser: name, expiry date, and a chain that ends at a trusted authority.
  3. Fix whichever of causes 1 to 3 you find, restart the service and wait several minutes.
  4. If the display is S1 to S3, decide between HTTP on a trusted network and replacement.

How to confirm it worked​

  • The display appears under Device > Unapproved, or reconnects if it was registered before.
  • A check from another PC shows the full chain, not just your own certificate.
  • It stays connected after a power cycle of the display, which clears its cached server address.

Checked against MagicINFO Server 21.1070 on Windows, October 2026. Items marked reported come from other installs on the builds named.

Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.

Last updated on