Conquering the Last Mile

Getting a renewed certificate onto a running service is often the part that still needs a person. The certificate is ready, but someone has to put it in the right place, sort out permissions and tell the application to use it.

That work looks different on every service. nginx reads files. A container may need those files copied into a volume. IIS needs a certificate in the Windows store and the right thumbprint on its HTTPS binding. These are familiar administration tasks, but they become a recurring burden when every renewal depends on somebody doing them by hand.

CertLocker Automations brings that work into the certificate workflow, using token based access over standard SSH and SFTP. There is no CertLocker deployment agent to install on the target, including when access runs through a bastion.

Your team controls the commands. CertLocker handles the managed access route, certificate delivery and execution, with progress and results in the platform.

Starting a new deployment setup

The destination comes from the host and token configuration, not from a server address hidden in the script.

1. Add the hosts. Register each server's name, connection address and SSH port. The host wizard can create the first host, its PEM credential and a matching access token together. Add further servers through Hosts.
2. Scope the access token. Create a HOST token, choose its lifetime, allow SSH and SFTP, and select the hosts it may reach. Associate the SSH credential. Use the configured bastion route where the target requires it.
3. Choose the automation's targets. In Automations, choose Certificate for installation or Challenge for validation file delivery. Select the host token, then tick the hosts this particular automation should run against. The picker lists the hosts allowed by that token.
4. Save the service procedure. Add the install, exec and audit commands. Their paths and activation commands determine where the material goes on each selected host.
5. Run it or attach it to issuance. Run a Certificate automation against a selected certificate, or associate the appropriate automation with an outbound ACME order. A Challenge automation handles validation content separately.

The walkthrough shows the access setup and host selection before the deployment examples, so the connection between the token, target checkboxes and script is visible.

Standard SSH. Token controlled access. No target agent.

Adding certificate automation should not mean distributing another proprietary service across your servers. With CertLocker, the target uses its normal SSH server. Certificate material travels over SFTP, and deployment commands run over SSH.

The access control sits in CertLocker. A scoped host token authorises access to the intended machine and protocols, with expiry and lifecycle controls. The managed host supplies the connection details and associated credentials. The destination account still determines which files and service operations are permitted.

For a private host reached through a bastion, the automation uses the configured access route. It does not need a CertLocker agent on the destination or a separate deployment method just because the server is behind that boundary. The route must be reachable, and the token must allow the SSH and SFTP operations the script needs.

This is a practical distinction for the team maintaining the estate: no CertLocker deployment daemon to package, roll out, patch or keep running on each target. You keep standard SSH access and manage the automation, permissions and execution from the platform.

It also keeps the service procedure visible. On Linux, reviewers see the Linux commands. On Windows, they see PowerShell. Neither requires a hidden payload or a remote desktop session.

What the last mile actually involves

ACME gives certificate validation and issuance a common protocol. It does not decide where your application reads its key, whether HAProxy needs a combined PEM, or which IIS binding should receive a renewed certificate.

CertLocker Automations lets the service owner express those decisions as a readable script attached to the deployment workflow. The certificate comes from the managed inventory or a new issuance order. The script names the material to transfer and the commands needed to install and activate it.

A deployment you can read in five lines

For a prepared, host installed nginx service, the procedure can look like this:

install certificate.chain to /etc/nginx/ssl/fullchain.pem mode 644
install certificate.privateKey to /etc/nginx/ssl/privkey.pem mode 600
exec sudo nginx -t
exec sudo systemctl reload nginx
audit true Deployed certificate.name to host.name

The first two lines transfer the selected certificate chain and private key. The next two check nginx configuration and reload the service. The final line records an audit message.

Each remote command has its own exec prefix and starts a fresh session. That makes the steps easy to review, but it also means variables from one command are not available to the next. Persist any information that a later step needs.

Before using this example, prepare the destination directories, nginx configuration and account permissions. SFTP writes as the destination account; an install line does not gain sudo privileges. Restrict noninteractive sudo to the commands the procedure needs. For production, include a staging and recovery plan: replacing two files directly is not an atomic rollout.

Windows IIS, with OpenSSH Server

IIS can use the same agentless approach as Linux. Install and enable Windows OpenSSH Server, then let CertLocker deliver the certificate over SFTP and run the deployment through PowerShell over SSH. There is no CertLocker Windows agent and no RDP session in the deployment procedure.

OpenSSH Server is the standard Windows remote access component, not an IIS plugin. Make sure the sshd service is running and configured to start automatically, and allow SSH from the intended management route. Microsoft documents the version specific steps in its Windows OpenSSH Server setup guide.

Register the Windows host in CertLocker, associate its credentials and select a scoped token allowing SSH and SFTP. The Windows account needs access to the staging directory and permission to import the certificate and update the intended IIS binding. If the host is reached through a bastion, configure that route on the managed host.

A PEM to IIS deployment then follows this sequence:

1. Transfer the combined certificate and private key PEM to a protected staging directory.
2. Convert it to PFX using the configured OpenSSL executable.
3. Import the PFX into Cert:\LocalMachine\My and save the resulting thumbprint for the next step.
4. Apply the thumbprint to the intended HTTPS binding, checking the site, port and hostname.
5. Run the site activation action appropriate to that deployment, then check the endpoint.

PowerShell commands stay readable in the automation editor. Because each execution is a separate session, saving the imported thumbprint avoids relying on a variable that disappears when the previous process exits. Prepare the conversion tool and protect temporary files before scheduling unattended renewal.

The important part is that the Windows work is included in the workflow. It is not a certificate download followed by an instruction to log into IIS Manager.

Start with issuance, not a certificate someone uploaded

An automation can use an existing certificate, but the workflow can also begin with a new ACME order. Configure the issuer, choose the names and validation method, and associate the certificate deployment with the order. CertLocker carries the resulting certificate into the delivery procedure.

For DNS validation, a configured provider such as Cloudflare publishes the validation records in the relevant zone. The provider credentials and zone access belong to that validation configuration; they do not need to be added to every destination server.

For IIS HTTP validation, a separate Challenge automation publishes the validation content into the site's /.well-known/acme-challenge/ path over SSH/SFTP. The CA retrieves that content through HTTP. After issuance, the Certificate automation handles import and binding. Keeping those two stages separate makes their purpose clear: one proves control of the name, the other installs the certificate.

The chosen CA must be able to reach the challenge URL. If the IIS site is private and that route is not available, DNS validation can validate through the DNS provider instead. Choose the validation method to fit the service and network, rather than opening a private site solely to accommodate the workflow.

Keep the procedure specific to the service

A mixed estate needs more than one installation recipe. nginx and Apache may read separate PEM files; HAProxy may use a combined PEM. Container services such as RabbitMQ need the certificate in the location the container actually reads, with ownership that allows the service account to open the key. Java application servers can require a key store conversion. IIS uses the Windows certificate store and HTTPS bindings.

The access model can remain the same across those differences. The script changes to match the service, packaging and activation procedure. That is where the service owner's knowledge belongs, in commands the team can inspect and maintain.

Keep those commands focused on deployment. The automation runner has a ten second budget for the whole run, including connection setup, transfer and execution across its targets. Install tools and prepare directories beforehand; do not put package installation or a lengthy application warm up into that window. Certificate issuance is a separate workflow stage.

If a run fails or times out, inspect the per host output and the target before retrying. A timeout does not guarantee that every remote operation has stopped, and a successful command does not necessarily tell you that the application is serving the new certificate.

Check what the service is presenting

The automation result tells you how the deployment commands finished. The separate Probes feature lets you observe the endpoint and inspect its certificate. Use the expected hostname and SNI context where multiple sites share an address.

Compare the served certificate with the managed record, then check the application response required by that service. Workflow progress, command output, audit history and endpoint observations answer different operational questions. Keeping them together makes renewal easier to investigate without treating a green status as the whole answer.

Put the service procedure into the renewal workflow

Start with one service your team already maintains. Set up its managed host and token, write down the installation steps and turn those steps into an automation. Include the issuer and validation method, then check the resulting certificate at the endpoint.

For an IIS server, that means Windows OpenSSH Server, PowerShell and the right binding. For a Linux service, it means the correct files, permissions and reload command. Either can use the configured bastion route without installing a CertLocker deployment agent on the target.

That is what Conquering the Last Mile means in CertLocker: the practical installation work becomes part of the managed certificate workflow, instead of another manual job waiting after renewal.