Mango SSL Startup: Keystore Access, Not Port Conflict

The panel disappears after you set SSL to true in env.properties and restart Mango. Port 8443 never serves the login page, while setting SSL back to false restores normal service. Start with ma.log: this failure pattern points first to keystore loading, password validation, or operating-system file access—not to the HTTPS port itself.

Stop Trying the Wrong Fixes

A reboot does not repair an unreadable keystore, an incorrect password, or a certificate entry that lacks an accessible private key. It only repeats the same failed startup sequence.

Changing ports also wastes time after you have confirmed that no other process owns 8443. A port conflict matters only when the log reports a bind or address-in-use failure.

Do not treat ALPN as the startup blocker. ALPN affects protocol negotiation and may be desirable after HTTPS works, but its absence should not prevent Mango from starting HTTPS.

Putting Apache with a certificate proxy in front of Mango is a valid alternative architecture, not a repair for a broken embedded-SSL configuration. It adds another service and another configuration layer before you have identified the current fault.

Read the Startup Failure Before Editing Anything

Open ma.log immediately after one failed SSL startup. Preserve the first exception and its underlying cause; later messages may only report that the web service did not initialize.

Classify the message before changing the configuration:

• A file-not-found message sends you to the configured keystore path.
• An access-denied message sends you to operating-system ownership and read permissions.
• A password, integrity-check, or key-recovery message sends you to the keystore password and key password.
• A missing-key or unusable-entry message sends you to the entry type and private-key material.
• An address-in-use or bind message sends you back to port ownership.

Capture the complete exception text and timestamp. Do not diagnose from the blank panel alone.

Separate a Certificate from a Usable Server Key

A successful keytool listing proves that a keystore can be opened in that command context. Mango still needs a server identity it can use during TLS initialization.

Check that the intended entry contains a private key, not only a trusted certificate. HTTPS cannot present a server identity using a certificate-only entry when the matching private key is absent.

Two credentials can matter: the password that opens the keystore and the password protecting the private-key entry. If they differ, both configured values must match their respective objects. Re-entering the same wrong value or testing only the keystore password leaves the failure unchanged.

Also compare the keystore used by keytool with the path in env.properties. Relative paths can resolve from the service working directory rather than the directory used in an interactive shell. Use the path resolution shown by the running service and verify that it reaches the intended file.

Test Access as the Mango Service Account

Your interactive login and the Mango service can run under different operating-system accounts. A keystore that you can list may still be unreadable by the service.

Start here: identify the account that launches Mango, then inspect permissions on the keystore file and every parent directory in its path. The service account needs enough directory traversal access to reach the file and read access to open it.

Keep the keystore protected. Do not grant broad access merely to make the test pass. Assign access to the service identity or an appropriate restricted group, restart Mango, and read the new log entry.

If the keystore resides on a mapped drive, user profile path, or other account-dependent location, test whether that location exists in the service context. Moving the file is not the first fix; prove the access failure from the log and account-level test first.

Apply the Fix in a Controlled Sequence

1. Return SSL to false and start Mango so you have a known working baseline.
2. Stop Mango cleanly before editing env.properties or replacing the keystore.
3. Confirm that the configured keystore path identifies the same file successfully inspected with keytool.
4. Verify that the intended keystore entry includes the server certificate and its matching private key.
5. Check the keystore password and the key password independently. Correct the value that corresponds to the startup exception.
6. Grant the Mango service account read and path-traversal access without exposing the private key to unrelated users.
7. Set SSL to true, retain port 8443, and start Mango once.
8. Read ma.log from that attempt before making another change. If the error category changes, follow the new underlying cause rather than repeating the previous fix.

After HTTPS starts, you may enable ALPN by copying the extension from [MANGODIR]/bin/extensions-available to [MANGODIR]/bin/extensions-enabled. Treat that as post-startup protocol configuration, not as the remedy for keystore initialization.

Verify the Repair and Avoid Regression

• Confirm that Mango remains running after SSL initialization.
• Open the interface through HTTPS on 8443.
• Check ma.log for keystore, key-recovery, permission, and bind exceptions.
• Restart the service once more to prove the fix survives a normal service cycle.
• Run the restart under the actual service identity, not only from an administrator shell.
• Record the active keystore location and which credentials protect the store and key, but do not place plaintext passwords in service notes.

Do not declare success because the process remains present for a few seconds. Verify the HTTPS endpoint and review the completed startup log.

FAQ