Post-Install

First Login

How you sign in for the first time depends on the authentication you configured during setup. In every case the administrator account is the email you supplied (orgAdminEmail).

• External OIDC provider. The login screen shows a sign-in button labelled with the provider name you entered at setup. Authenticate through your identity provider with the account whose email matches orgAdminEmail; you sign in through the provider rather than with a Manifest password or a reset email. The provider's issuer URL must be reachable from the cluster.

• SMTP, no external OIDC. Follow the password-reset flow on first sign-in; the reset email is delivered through your mail server.

• Neither SMTP nor external OIDC. The platform cannot send a reset email, so sign in with the initial password the installer generated, then change it from account settings. Retrieve it from config.yaml:

  Shell

  manifest-installer deploy-config decrypt | grep orgAdminInitialPassword

  deploy-config decrypt prints the config to stdout whether or not it is encrypted. Use orgAdminInitialPassword (the application login), not keycloakAdminPassword (the Keycloak service-admin console), which the Manifest sign-in screen rejects.

Add Ingress Certificate to Trust Store

📘

Using your own certificate?

Skip the steps below. They distribute the CA Manifest generates, which your deployment no longer serves. Client machines still need to trust the CA that issued your certificate — usually already handled by whatever distributes your organization's root, but worth confirming before users hit the site. See Use a Custom Ingress Certificate.

Manifest generates a self-signed CA certificate for the web ingress. To avoid browser security warnings, you must export this certificate from the cluster and trust it on every machine that will access the platform's web UI.

Export the CA Certificate

Run on the Manifest host:

kubectl get secret -n cert-manager ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > manifest-ca.crt

Distribute manifest-ca.crt to user workstations and apply one of the OS-specific commands below to trust it.

Trust the Certificate

macOS

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain manifest-ca.crt

Linux (Ubuntu/Debian)

sudo cp manifest-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Linux (RHEL/CentOS)

sudo cp manifest-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Windows (PowerShell as Administrator)

Import-Certificate -FilePath manifest-ca.crt -CertStoreLocation Cert:\LocalMachine\Root

Use a Custom Ingress Certificate

By default Manifest issues the browser-facing certificates from a CA it generates in the cluster. If you run your own PKI, you can supply your own material instead. Internal service-to-service TLS stays on the generated CA either way.

Which of two ways applies is decided by what your PKI will release, not by anything you configure:

The installer inspects what you give it and says which reading it took in its closing summary.

What the Certificate Must Cover

This applies when you supply a server certificate. A single leaf covering every browser-facing hostname under your base domain. With example.com as the base domain, a *.example.com wildcard covers all of these:

Plus one more, which the wildcard above does not cover:

A wildcard matches exactly one label, so *.example.com does not reach *.buckets.example.com. Object storage needs it for per-bucket virtual hosts. Ask your CA for both wildcards.

Setup validates the certificate against this list and rejects one that falls short, so you find out before deploying.

What the Subordinate CA Must Allow

This applies when your PKI will not release a server certificate but will delegate a CA. Its private key comes with it — Manifest is the one issuing from it.

Constrain it to your base domain; Manifest never asks it for anything else. With example.com as the base domain:

[ v3_constrained_intermediate ]
basicConstraints       = critical, CA:TRUE, pathlen:0
keyUsage               = critical, keyCertSign, cRLSign
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always
nameConstraints        = critical, @nc

[ nc ]
permitted;DNS.0 = example.com
excluded;IP.0   = 0.0.0.0/0.0.0.0
excluded;IP.1   = 0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

If your PKI attaches an extended key usage, it must include serverAuth.

📘

A leading dot is narrower, not broader

permitted;DNS = .example.com excludes example.com itself. Use the bare form unless you specifically want to exclude the base domain.

Setup checks all of this before writing anything, including the chain above your CA — a root with an exhausted path length can leave an otherwise-valid CA unable to issue.

Supply the Certificate at Setup

Have three PEM files ready on the host:

Run manifest-installer setup, choose Custom ingress TLS from the optional-page selector, and give it the three paths. Then deploy as usual.

All three are set together or not at all. Leaving them empty is the default in-cluster-CA behavior.

If You Have a PKCS#12 Bundle

If your PKI handed you a single .p12 or .pfx file, give it at the certificate prompt instead of a PEM. Manifest recognises it, asks once for its passphrase, and fills in the key and trust chain itself. This works for either shape.

The passphrase decrypts the bundle and is never stored. If the bundle carries no root CA — many exports stop at the issuing CA — the trust chain prompt stays, asking for just that.

📘

Bundles are interactive only

There is nowhere to ask for the passphrase otherwise. An unattended install supplies the three PEM files directly.

Rotate the Certificate

1. Put the new PEM files on the host.

2. Run manifest-installer setup and select the Custom ingress TLS page. An empty answer keeps the previous value, so re-enter only what changed.

3. Deploy at the version you are running:

   Shell

   manifest-installer deploy --version <installed-version>

❗️

Do not edit configuration by hand

Do not edit config.yaml directly, and do not kubectl edit the ingress secrets. A hand edit breaks the config's integrity check, and a change made directly in the cluster is reverted by the next deploy. Use manifest-installer deploy-config edit to change values outside a setup re-run.

To return to the generated in-cluster CA, clear all three values with manifest-installer deploy-config edit and deploy again.

Check the Certificate and Its Expiry

A server certificate must be renewed manually. Track its expiry alongside your other renewals — when it lapses, browsers show a certificate error and in-cluster sign-in stops working until you rotate.

A subordinate CA renews the certificates it issues automatically. The CA itself does not. Track its expiry instead: past that date, anything chained to it fails validation.

echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

To check the full chain a browser receives, verified against your own root:

echo | openssl s_client -connect app.example.com:443 -servername app.example.com \
  -showcerts -CAfile /path/to/your-root-ca.pem -verify_return_error

If browsers are satisfied but signing in loops back to the login screen, see Troubleshooting.

Related Documentation

• Configuration Reference - Setup wizard values and day-2 configuration changes
• Troubleshooting - Common issues and solutions