Build a self-hosted certificate service, verify it locally, then make selected endpoints available remotely
Ultimate Certificate Manager, or UCM, provides a web interface for managing certificate authorities, certificates, ACME enrollment, revocation services, and related PKI operations. In this guide, we install UCM with Docker, preserve its application data, secure the initial administrator account, plan a private CA hierarchy, and prepare an ACME service for internal certificate automation. We then verify the deployment locally before connecting the working service to an HTTP/s tunnel with Localtonet. The result is a practical workflow for authorized remote administration or ACME access without configuring inbound router port forwarding or requiring a public IP address.
📋 What's in this guide
Understand the architecture before installing anything
Ultimate Certificate Manager is a self-hosted Certificate Authority management platform. Its documented capabilities include root and intermediate CA management, certificate issuance and revocation, certificate templates, ACME, SCEP, EST, OCSP, CRL/CDP publication, AIA, SSH certificate authorities, certificate discovery, approval workflows, role-based access control, audit logs, backups, and several authentication options. This guide concentrates on the narrower task of running a private X.509 CA and making its ACME service available to authorized clients.
ACME is the Automatic Certificate Management Environment protocol standardized by RFC 8555. Instead of having an administrator manually generate, approve, export, distribute, and renew every certificate, an ACME client creates an account, submits an order, proves control of the requested identifier, finalizes a certificate signing request, and downloads the resulting certificate chain. ACME also defines certificate revocation and other account and order operations.
A private ACME CA uses the same general automation model for certificates that are trusted inside an organization, lab, home network, development environment, or controlled device fleet. It does not automatically become a publicly trusted CA. Every system that must trust certificates issued by the private hierarchy needs the appropriate root certificate installed through an authorized trust-store management process.
There are three separate trust and transport questions in this design. First, administrators need a protected way to reach the UCM web interface. Second, ACME clients need network access to the configured ACME directory and resource URLs. Third, relying applications need to trust the private root CA. A tunnel addresses network reachability. It does not install the root certificate, authorize ACME accounts, choose certificate profiles, or replace UCM authentication.
Publishing UCM or an ACME directory through Localtonet changes how authorized users and clients reach the service. It does not add the private root to browser, operating-system, application, or device trust stores. Distribute the root certificate only through a controlled process, verify its fingerprint through an independent channel, and never distribute a CA private key.
Prerequisites and deployment decisions
This tutorial uses UCM's documented Docker installation because it provides a concise, reproducible deployment with a persistent named volume. Before continuing, prepare a host with Docker installed and permission to create a container, publish host ports, and create a Docker volume. The host must have enough storage for application data, issued certificates, logs, and backups. Capacity depends on your certificate volume and retention policy, so no universal storage size should be assumed.
The documented Docker command publishes TCP ports 8443 and 8080 and stores data in the named volume ucm-data. UCM's getting-started material identifies https://localhost:8443 as the local web address. The supplied project evidence does not define the purpose of every listener in enough detail for this article to assign services to port 8080. Do not expose, tunnel, or firewall a listener merely because it appears in an installation command. Confirm its role in the documentation for the exact UCM release you deploy.
You should also make several PKI policy decisions before creating a CA. Decide which names or IP identifiers the CA may issue, how long end-entity certificates should remain valid, whether requests require approval, which ACME validation methods fit your environment, who may administer UCM, and how backups and recovery will be protected. If an organization already has a PKI policy, UCM should implement that policy rather than silently creating a second, unrelated trust hierarchy.
| Requirement or decision | Why it matters | Recommended preparation |
|---|---|---|
| Docker host | Runs the UCM container and owns its persistent volume | Install and test Docker using the supported procedure for the host operating system. |
| Available host ports | The documented command publishes 8443 and 8080 | Check for conflicts and limit host-level reachability according to your network policy. |
| Persistent storage | CA records, configuration, and other application data must survive container replacement | Use the documented ucm-data named volume and include UCM data in a tested backup plan. |
| CA hierarchy | The hierarchy defines trust boundaries and which key signs operational certificates | Prefer a carefully protected root and an appropriate issuing intermediate when your policy requires separation. |
| Identifier scope | A private CA should not issue arbitrary names without policy controls | Define permitted DNS names, IP ranges, and other identifiers before enabling automated enrollment. |
| ACME authorization | Reachability alone must not authorize certificate issuance | Plan account controls, approval rules, External Account Binding where appropriate, and restricted certificate profiles. |
| Remote hostname | ACME clients depend on a directory URL and related resource URLs | Choose the Localtonet process type deliberately and avoid changing a production directory address casually. |
| Trust distribution | Clients will reject private certificates until the root is trusted | Use managed trust deployment and verify the root fingerprint independently. |
UCM also publishes Debian/Ubuntu and RPM installation paths and a Helm chart for Kubernetes. Those paths have different service-management, package, and persistence considerations. To keep the workflow coherent and verifiable, the commands below use the documented Docker image rather than mixing several deployment models.
Install Ultimate Certificate Manager with Docker
The official UCM getting-started command creates a container named ucm, publishes ports 8443 and 8080, configures Docker to restart the container unless it is explicitly stopped, and mounts the named volume ucm-data at /opt/ucm/data. Run it on the host selected for the CA.
Confirm that the host is suitable
Verify that Docker is installed, ports 8443 and 8080 are not already assigned, and you have permission to create containers and volumes. Keep the host patched and restrict administrative access because it will store CA data.
Start the documented UCM container
Run the official Docker command exactly as shown. The named volume is essential because container files outside persistent storage should not be treated as durable application data.
Open the local HTTPS interface
From the Docker host, open https://localhost:8443. If you administer from another authorized machine, substitute the host's approved network name or address only after confirming that host-level access is permitted.
Sign in with the initial account
The documented initial credentials are username admin and password changeme123. Use them only for the first local sign-in. Do not publish the service while these credentials are active.
Complete security initialization
Replace the initial password immediately, review the available authentication and access-control settings, and record recovery and backup procedures before creating production CA material.
docker run -d --restart=unless-stopped \
--name ucm \
-p 8443:8443 \
-p 8080:8080 \
-v ucm-data:/opt/ucm/data \
neyslim/ultimate-ca-manager:latest
Using the latest image tag follows the project's published quick-start command, but it also means the tag can resolve to a different release in the future. For a controlled production deployment, establish an upgrade and rollback policy and review UCM's release and upgrade information before replacing a running container. Do not assume that recreating a CA service is equivalent to upgrading an ordinary stateless web application.
UCM also provides package commands for Debian/Ubuntu and RHEL-family distributions. Those commands dynamically resolve the latest release package and enable the ucm systemd service. They are valid documented alternatives, but a host should use one installation model rather than running the package and Docker deployments on the same ports.
Debian and Ubuntu package path
url=$(curl -fsSL https://api.github.com/repos/NeySlim/ultimate-ca-manager/releases/latest \
| grep '"browser_download_url".*_all\.deb"' | cut -d'"' -f4)
curl -fsSL -o ucm.deb "$url"
sudo apt install ./ucm.deb
sudo systemctl enable --now ucmRHEL, Rocky Linux, and Fedora package path
url=$(curl -fsSL https://api.github.com/repos/NeySlim/ultimate-ca-manager/releases/latest \
| grep '"browser_download_url".*\.noarch\.rpm"' | cut -d'"' -f4)
curl -fsSL -O "$url"
sudo dnf install ./ucm-*.noarch.rpm
sudo systemctl enable --now ucmThe package commands above intentionally install the latest release returned by GitHub. Review the resolved release and your change-management requirements before using that behavior in an automated production process.
Secure UCM before creating or exposing a CA
A certificate authority is not just another dashboard. It can issue identities that other systems trust. An administrator account takeover, unrestricted ACME profile, leaked signing key, or unverified backup can affect every relying system in the hierarchy. Complete the security baseline while UCM is still reachable only through your approved local path.
UCM supports root and intermediate CAs, offline operation, externally signed CAs, HSM-backed keys, and RFC 5280 name constraints. These are building blocks, not automatic policy. For a small disposable laboratory, a simple hierarchy may be enough. For a longer-lived organizational deployment, a protected root and one or more issuing intermediates usually create a more manageable boundary. The root can be kept out of routine issuance while the intermediate handles day-to-day certificates.
Keep UCM local until the default administrator password has been changed, the intended CA hierarchy has been reviewed, backups have been configured and tested, and ACME issuance rules have been restricted. A Localtonet tunnel provides reachability, not application authorization.
Create a private CA hierarchy in UCM
UCM's interface supports creating root and intermediate authorities and viewing their hierarchy. Exact form fields and labels can change between releases, so this guide does not invent a click-by-click sequence that may be wrong for the installed version. Use the contextual help available from UCM's toolbar while following the policy-driven sequence below.
Define the CA's purpose and permitted scope
Document whether the hierarchy will issue server, client, device, code-signing, email, or other certificates. Specify permitted DNS namespaces, IP ranges, email subtrees, validity limits, approved key types, and who may authorize issuance.
Create or import the root authority
Use UCM's CA management interface to create the root appropriate to the policy, or import an existing authority only through an approved migration process. UCM supports configurable RFC 5280 profiles and name constraints at CA creation.
Protect the root signing key
Decide whether the root should operate offline, use an HSM-backed key, or follow an externally signed workflow. Avoid using a broadly accessible root key for routine end-entity issuance when the deployment's risk warrants separation.
Create an issuing intermediate where required
Create an intermediate beneath the root and constrain it to the intended namespace and certificate uses. UCM can display the hierarchy and supports intermediate revocation from the parent.
Create restricted certificate templates
Use templates for the intended server, client, code-signing, email, or smartcard use cases. UCM documents RSA and EC key choices, subject defaults, Key Usage, Extended Key Usage, and typed SAN validation.
Issue a controlled test certificate
Before enabling unattended enrollment, issue a test certificate from the intended issuing CA. Check the subject, SANs, issuer, validity, key usage, extended key usage, chain, and revocation publication information.
Distribute only the trust material that clients need
Export the public root certificate and any required intermediate certificates. Verify fingerprints through an independent channel and deploy them with an authorized trust-management process. Never export or distribute the root private key for client trust.
Name constraints deserve particular attention. UCM supports permitted and excluded DNS, IP-range, and email subtrees and enforces them across issuance paths. Correct constraints can reduce the damage caused by a mistaken or unauthorized request, but incorrect constraints can also make legitimate certificates unusable. Test them with representative names before broad deployment.
Revocation should also be operational before relying systems depend on the CA. UCM includes CRL/CDP and OCSP capabilities, and it records RFC 5280 revocation reasons. Whether a specific application checks CRLs or OCSP depends on that application, its configuration, and its network access. Do not assume that publishing revocation endpoints guarantees that every client validates them.
Configure UCM as a private ACME CA
UCM implements an RFC 8555 ACME server and documents HTTP-01, DNS-01, and TLS-ALPN-01 challenges, wildcard support, IP identifiers, CAA checking, External Account Binding, Renewal Information, named certificate profiles, and per-request CA selection. The right configuration depends on the clients, identifiers, and network topology in your environment.
The installed UCM release is authoritative for the exact ACME configuration fields and generated directory URL. Do not construct an endpoint by guessing a path. Create the ACME configuration in UCM, copy the directory URL displayed by the application, and test that exact value with a non-production client.
| ACME option | Best suited to | Important consideration |
|---|---|---|
| HTTP-01 | DNS names whose web service can answer the required HTTP challenge path | The ACME validation service must be able to reach the challenge response at the expected identifier and port. |
| DNS-01 | Wildcard certificates and environments where DNS automation is available | The client or integration needs authorized control of the required TXT record, and DNS propagation behavior must be considered. |
| TLS-ALPN-01 | Services able to present the special validation response over TLS | Proxies, load balancers, or tunnels must preserve the validation behavior expected by the ACME server. |
| External Account Binding | Environments that need a separate authorization step before an ACME account can register | EAB credentials are secrets. Provision, rotate, and revoke them through a controlled process. |
| Named certificate profiles | Separating issuance policies by workload or certificate purpose | Bind profiles to appropriately restricted templates and avoid allowing clients to request broader usages than necessary. |
Select the issuing CA
Choose the intermediate intended for automated issuance. Avoid assigning the root directly to routine ACME enrollment unless a reviewed policy specifically requires that design.
Define an issuance profile
Restrict allowed identifiers, certificate purpose, template, key usage, extended key usage, validity, and any approval requirements according to the workload.
Choose supported validation methods
Enable only the challenge methods that can be validated correctly in your topology. Wildcard requests require an appropriate DNS-based workflow rather than ordinary HTTP validation.
Decide how ACME accounts are admitted
Where clients should not self-register freely, use UCM's available account controls and consider External Account Binding. Treat EAB identifiers and HMAC keys as credentials.
Copy the generated directory URL
Obtain the directory URL from the running UCM interface. Do not infer it from examples or assume that the path remains identical across releases and configurations.
Enroll a test client
Configure a non-production ACME client with the displayed directory URL, install the private root through an approved trust process, and request a certificate for an identifier permitted by the profile.
Test renewal and revocation
Confirm that the client can renew through the same profile and that a revoked test certificate appears correctly in UCM's lifecycle records and configured revocation services.
A client may be able to reach UCM's ACME directory through a Localtonet URL while UCM is still unable to validate the requested identifier. HTTP-01, DNS-01, and TLS-ALPN-01 validate different resources. Design and test the complete validation path for the chosen challenge instead of assuming that the tunnel solves every ACME networking requirement.
Verify the local deployment before adding remote access
Local verification isolates UCM configuration problems from tunnel configuration problems. If the service does not work on the host, a public URL will not fix it. Complete the following checks while connecting directly to https://localhost:8443.
Verify the sign-in page and administrator access
Confirm that the HTTPS interface loads, the replacement administrator credential works, and the original bootstrap password no longer grants access.
Inspect the CA hierarchy
Confirm that the intended root and intermediate relationship is visible and that the issuing CA uses the expected profile, constraints, and key-protection mode.
Inspect the test certificate
Check its serial number, issuer, subject, SANs, validity, Key Usage, Extended Key Usage, and chain. Confirm that prohibited names or uses are not accepted.
Verify the exact ACME directory URL
Use the URL presented by UCM and ensure the test ACME client can retrieve the directory. A directory response proves API reachability, but not successful authorization or issuance.
Complete a test order
Request a certificate within the permitted scope, complete the selected challenge, and verify that the order reaches a valid state and returns the expected certificate chain.
Confirm backup and recovery readiness
Create a protected backup using UCM's supported facilities and verify the documented restore process in an isolated environment before treating the CA as production-ready.
A browser warning during the first local visit can have several causes, including an untrusted private certificate or a hostname mismatch. Do not train administrators to ignore certificate warnings permanently. Inspect the certificate, verify that you reached the intended host, establish trust through the approved root-distribution process, and issue a certificate whose SAN matches the administrative hostname.
Connect the verified UCM service through Localtonet
Once UCM works locally, we can expose the required HTTP-based service through Localtonet. The Localtonet client must run on the UCM host or on another device that can reach it. Our client establishes an outbound connection to a Localtonet relay, so the deployment does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
UCM's documented local interface uses HTTPS on port 8443. When creating the tunnel, select the current HTTP/s option that correctly matches the local service's protocol. The exact dashboard naming and upstream TLS choices can vary, so verify them in the current interface rather than treating an ordinary cleartext HTTP target as interchangeable with https://localhost:8443.
Install and run the Localtonet client
Run the Localtonet client on the UCM host or on an authorized device that can reach the UCM listener. Keep the client running for as long as remote access is required.
Authenticate the intended device
Select the device using its device-specific authentication token. Do not paste the token into documentation, source control, support messages, screenshots, or command examples.
Select an available relay server
Choose a currently available server or region from the dashboard. Available values can vary and must be taken from the current product rather than hardcoded into deployment instructions.
Create the HTTP/s tunnel configuration
Point the tunnel to the local IP address that reaches UCM and port 8443, using the HTTP/s configuration appropriate for UCM's local HTTPS listener. Choose Random Sub Domain, Custom Sub Domain, or Custom Domain according to availability and your hostname requirements.
Start the tunnel
Creating a tunnel does not start it. Use the Start button, then wait for the selected client and tunnel to show that they are connected and running.
Test the assigned public address
Open the assigned public HTTPS URL from an authorized external network. Verify authentication, administrator access, and the specific ACME directory URL before changing any production client.
HTTP and File Server tunnels support Random Sub Domain, Custom Sub Domain, and Custom Domain process types. All three serve content at a public HTTPS address. A stable hostname is particularly important for an ACME directory because clients store that URL and the directory returns additional resource URLs. If you intend to use a custom domain, check the current Localtonet documentation for its DNS requirements instead of guessing records or targets.
For current dashboard guidance, consult the Localtonet HTTP tunnel documentation. Keep in mind that tunnel availability depends on both sides of the path: the selected Localtonet client must remain connected, the tunnel must be running, and UCM must remain reachable from that client.
If your UCM release and network architecture allow ACME traffic to be separated from the administrative interface, expose only what remote clients require. The evidence available for this guide does not establish a universal UCM listener or path-separation procedure, so verify the behavior of your installed release before relying on path filtering. Always retain UCM authentication, ACME account controls, least privilege, and monitoring.
Routine operations, upgrades, and troubleshooting
Operate the tunnel as a dependency, not as the CA itself
The tunnel provides a route to UCM. CA state remains in UCM, and trust remains on the client systems. If remote access fails, determine whether the UCM application, the local listener, the Localtonet client, the selected device, or the tunnel lifecycle is responsible. A tunnel that exists in the dashboard but has not been started is not available.
Back up before upgrades
UCM is actively developed, and release notes may include database, key-encryption, backup, integration, or dependency changes. Review the release notes and the project's upgrade guidance before changing versions. Create a protected backup, verify that the backup is usable, document the current image or package version, and plan a rollback. The Docker named volume provides persistence, but persistence by itself is not a backup.
Keep directory URLs and trust anchors under change control
Changing a public hostname can affect configured ACME clients. Changing a root CA can affect every relying application. Treat either change as a migration with inventory, testing, overlap where appropriate, and a rollback plan. Do not delete an old hierarchy merely because a replacement has been created.
| Symptom | Likely area | What to check |
|---|---|---|
https://localhost:8443 does not load |
UCM container, host port, or local firewall | Confirm the deployment completed, the selected installation model is running, and no other service owns port 8443. |
| The public URL is unavailable | Localtonet client or tunnel lifecycle | Confirm the selected device is connected, the tunnel was explicitly started, and the client device can still reach UCM. |
| The public URL opens the wrong service | Local target configuration | Recheck the local IP, port 8443, and whether the HTTP/s tunnel mode matches UCM's HTTPS listener. |
| ACME directory loads but orders fail | Account policy, profile, identifier, or challenge path | Inspect the ACME error, account admission rules, selected CA, profile restrictions, DNS, and challenge reachability. |
| ACME reports an unauthorized or rejected identifier | Authorization or issuance scope | Confirm the requested SAN is permitted by the ACME profile, CA constraints, and selected validation method. |
| Wildcard issuance fails | Challenge selection or DNS automation | Use an appropriate DNS-01 workflow and verify that the expected TXT record is created and visible where UCM checks it. |
| Issued certificate is not trusted | Client trust store or incomplete chain | Install the correct private root through an authorized process and verify that the service presents the needed intermediate chain. |
| Browser reports a hostname mismatch | Certificate SAN | Issue a certificate containing the exact administrative hostname. Trusting a root does not correct a SAN mismatch. |
| Renewal worked locally but fails remotely | Changed URL, stopped tunnel, or unavailable client | Check the stored directory URL, public hostname, Localtonet client status, tunnel status, and the complete validation path. |
When an ACME client reports an error, preserve the exact problem type and detail. Standard ACME errors distinguish conditions such as malformed requests, bad nonces, unacceptable CSRs, unauthorized requests, rejected identifiers, DNS failures, connection failures, TLS failures, CAA restrictions, rate limiting, and server errors. Troubleshooting is faster when the actual error is investigated instead of repeatedly recreating accounts or orders.
UCM includes a page-specific help panel available from the toolbar. Use it to confirm current labels, endpoint generation, profile options, security settings, and operational behavior. This is especially important because UCM is actively developed and the exact interface can change between releases.
Frequently asked questions
Does a Localtonet URL make certificates from my private CA publicly trusted?
No. The tunnel makes the selected UCM service reachable. Public trust depends on the root certificates already trusted by an operating system, browser, application, or device. A private UCM root must be distributed to authorized systems through a controlled trust-store process.
Which local UCM port should the tunnel target?
The documented Docker deployment opens the web interface at https://localhost:8443, so this workflow targets port 8443 with an HTTP/s tunnel configuration appropriate for the local HTTPS listener. The installation also publishes port 8080, but the evidence available for this guide does not establish its exact role. Confirm every listener in the documentation for your installed UCM release before exposing it.
Can I expose UCM without router port forwarding?
Yes. The Localtonet client establishes an outbound connection to our relay server. The resulting tunnel provides a public URL without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The selected client must remain connected and the tunnel must be running.
Should I expose the UCM administration interface and ACME service together?
Expose only what authorized remote users or clients require. If your installed UCM release and architecture support separating administrative and enrollment access, that can reduce the exposed surface. This article does not claim a universal UCM path or listener separation because the exact behavior must be confirmed for the installed release.
Does Localtonet solve HTTP-01 or DNS-01 validation automatically?
No. A tunnel can make UCM's HTTP-based endpoints reachable, but each ACME challenge has its own validation requirements. HTTP-01 requires the expected HTTP challenge response, DNS-01 requires the correct DNS TXT record, and TLS-ALPN-01 requires the specified TLS behavior. Test the full validation path for the selected method.
Can UCM issue wildcard certificates through ACME?
UCM documents wildcard support. Wildcard ACME issuance requires an appropriate DNS-01 validation workflow. Configure DNS authorization carefully and restrict which accounts and profiles may request wildcard certificates.
Should ACME issue directly from the root CA?
A protected root with a separate issuing intermediate is generally easier to isolate from routine automation, especially for a long-lived organizational PKI. The correct hierarchy depends on your policy and risk model. UCM supports both root and intermediate authorities, offline operation, externally signed CAs, and HSM-backed keys.
What happens when the Localtonet client stops?
The public tunnel is available only while the selected client or device is connected and the tunnel is running. UCM can continue operating locally, but remote administrators and ACME clients using that public address will not be able to reach it until connectivity is restored.
Is the Docker volume enough for disaster recovery?
No. The named volume preserves UCM data when the container is replaced, but it remains part of the same deployment and can still be lost or corrupted. Use UCM's backup and restore capabilities, protect backup credentials and archives, store copies separately, and test restoration in an isolated environment.
Connect your verified private CA with Localtonet
After UCM is installed, secured, backed up, and tested locally, create an HTTP/s tunnel for the approved service and give authorized administrators or ACME clients a reachable HTTPS address without opening inbound router ports.
Get Started Free →
