Finlay.worksBareBones Ticketing manual

Install

HTTPS And Hostnames

How to set the approved host list, replace the bootstrap certificate, and enable reverse-proxy trust.

RC2 approved for evaluation Status: release-candidate Audience: System Administrator Source: c4b4d41

HTTPS And Hostnames

BareBones Ticketing runs its own HTTPS listener on TCP port 8443 by default. This page covers the three settings you control in the product: which hostnames the application answers to, which certificate it presents, and whether it trusts a reverse proxy in front of it.

Do this after First administrator — the settings here need a System Administrator sign-in.

Before you start

  • The application installed and reachable at its bootstrap address.
  • The DNS name or host address you intend to use, agreed with your DNS owner.
  • A decision on the certificate: keep the bootstrap self-signed certificate for now, or install your own PKCS#12/PFX file.
  • If a reverse proxy sits in front of the application: the exact proxy addresses or network ranges, and the forwarded-header limit, from your network owner.
  • A way back in if you lock yourself out. Saving a host list that excludes your own access name will do exactly that.

The bootstrap certificate

On first start the application generates a self-signed certificate so that setup is encrypted. Browsers warn about it. That warning is correct — the certificate proves nothing about the server's identity.

Use it only inside your approved bootstrap boundary. Replace it before anyone outside that boundary uses the system.

Set approved hosts and proxy trust

  1. Sign in as a System Administrator.

  2. Open Admin Settings, then Web Access and Session Security.

    Any System Administrator can read this page. Saving a change needs recent step-up verification — proving your identity again, shortly before the change.

  3. Under approved public hosts, enter the hostnames or IP addresses this deployment answers to, one per entry.

    Enter bare names. No scheme, no path, no whitespace. Do not copy entries from another environment.

  4. Do not use the unrestricted wildcard on a production deployment. The product presents it as suitable only for deliberately approved local review.

  5. Set reverse-proxy trust.

    • No external proxy: leave trusted proxy handling off. Forwarded headers are ignored.
    • External proxy in the request path: enter the exact proxy addresses or network ranges, and a forwarded-header limit between 1 and 10, then enable trusted proxy handling.

    This setting tells the application which forwarded headers to believe. It does not configure the proxy.

  6. Complete step-up verification.

  7. Review the proposed host and proxy settings, then save once.

    The save is durable and recorded in the audit trail. It does not change the running process. The new settings apply after restart.

The Internal self-API base is not one of your hostnames

The same page carries an Internal self-API base setting, with the field Loopback internal API base URL. Server-rendered workspaces use it for same-process calls back into the application, so that the public HTTPS certificate never decides whether internal actions succeed. It defaults to http://127.0.0.1:8080/ and the product accepts only a loopback IP address on that port — it is not a public URL, it is never used in email links, and it does not belong in your approved host list. Leave it alone unless the vendor tells you otherwise; like the settings above, a change applies after restart.

Install your own certificate

  1. Open Admin Settings, then HTTPS and Certificates.

  2. Read the running and saved certificate sources before you change anything.

  3. Choose the certificate source.

    • Bootstrap self-signed keeps the temporary certificate.
    • Operator-provided takes a PKCS#12/PFX file. See What the product checks below before you upload one.

  4. Enter the certificate password in the product's protected field. Do not record it anywhere else.

  5. Complete step-up verification and save once.

    The product stores the certificate and tells you whether a restart is required.

What the product checks in a certificate

Four things, and no more:

  • it parses as a PKCS#12 / PFX file;
  • the password you enter matches it;
  • it contains the private key — a certificate on its own is refused with "The provided certificate must include a private key.";
  • the file is 5 MiB or smaller.

Everything else is yours to get right, and the product will accept it without complaint.

  • Validity dates are recorded, not enforced. The product reads the not-before and not-after dates and shows them on the page, but an expired or not-yet-valid certificate installs exactly as cleanly as a current one.
  • The host name is not checked. Nothing compares the certificate's subject or its subject alternative names against your approved host list. A certificate for the wrong name is accepted.
  • The chain is not validated. A certificate signed by an issuer none of your clients trust installs just as readily as one signed by an issuer they do.

So a successful save means the file was readable and had a key in it. It is not the product telling you the certificate is correct, current, or trusted — check the dates, the names, and the chain before you upload, because nothing downstream will check them for you.

Restart and confirm

  1. Restart the application using the procedure for your platform. On Linux that is docker compose restart. On Windows, restart the BareBonesTicketing service — in an elevated PowerShell, Restart-Service -Name BareBonesTicketing (the method the Windows package's RUNBOOK.md specifies for a restart without an upgrade). Do not restart by any other means.

  2. Reach the application at its approved HTTPS name.

  3. Confirm that Web Access and Session Security lists only the hosts you intended.

  4. Confirm that HTTPS and Certificates shows the same source as running and as saved, and that no restart is still pending.

  5. Sign in normally through the intended address.

Where the product's responsibility ends

BareBones Ticketing manages its own listener, its stored certificate, the approved host list, and forwarded-header trust.

It does not obtain public certificates, renew certificates, create DNS records, configure firewall rules, configure a reverse proxy or load balancer, or approve exposing the system to the internet. Those stay with your infrastructure owners.

A certificate you install gives the application a real certificate. Whether clients trust it depends on your certificate chain, your DNS, and the network path.

If it does not work

You cannot reach the application after restart. Do not guess at host, proxy, or certificate settings repeatedly. Use your deployment's recovery procedure.

The saved certificate is missing or will not load after restart. The application falls back to the bootstrap self-signed certificate and reports that running and saved sources do not match. That fallback is not trusted. Fix the certificate through your certificate owner.

A certificate upload or save fails. Do not paste the certificate file or its password into a ticket or screenshot. Return the file to the certificate owner.

Windows local HTTPS verification failed during install. Read the recorded installer stage and the Event Viewer logs. Do not open an HTTP setup path and do not create a broad unnamed firewall rule.

Next step

Licensing.