SSL.com ACME automation and deployment

SSL.com issues the certificates. Getting them onto your systems is still on you.

SSL.com supports ACME, so a standard client with External Account Binding credentials can request certificates against your SSL.com account. That covers getting certificates. It doesn't cover getting them onto the load balancers, web servers, and appliances that present them, which is the work that repeats every renewal as lifetimes compress toward 47 days.

CertKit registers against SSL.com once, issues and renews from your account, and the CertKit Agent installs every renewal across your estate and verifies it is being served.

Start free trial Watch demo

SSL.com splits ECC and RSA

SSL.com runs a separate ACME directory for each key type. An account on the ECC directory only issues certificates with elliptic curve keys, and an account on the RSA directory only issues RSA. Request the wrong key type from the wrong directory and the order fails.

If you run both, say modern servers on ECDSA next to older appliances that still need RSA, every client has to know which directory to use for which certificate. CertKit adds SSL.com as two issuers with the same credentials, one per key type, and won't let you pair a certificate with the issuer that can't sign its key.

What SSL.com ACME still leaves on your plate

The do-it-yourself version, once you have EAB credentials:

Register every client against the right directory. One ACME account per directory per client, and a mix-up between ECC and RSA only shows up when an order fails.
Install and maintain a client per host. The usual rollout, version drift, and per-machine configuration.
Ship the full chain, every time. A hook that writes only the leaf, or that hardcodes an intermediate from an older certificate, works in a desktop browser and fails for API clients and mobile apps.
Write the post-deploy hooks. Convert, place, reference, reload, once per platform, run only at renewal.
Cover the appliances. Load balancers and gateways import certificates through an API. No ACME client does that.
Add monitoring and an audit record. Proof that the new certificate is being served, and a log of which certificate went where. Neither is part of an ACME client's job.

SSL.com handles issuance. The half it leaves is the one where a certificate has to arrive on a specific machine and take effect, which is where shorter lifetimes turn an occasional task into a permanent one.

How it works

    SSL.com              CertKit              Your systems
┌──────────────┐   ┌─────────────────┐   ┌──────────────────┐
│ ECC          │   │  register both  │   │                  │
│ directory ◄──────── with one key   │   │  ┌─────────────┐ │
│              │   │  + HMAC         │   │  │CertKit Agent│ │
│ RSA          │   │                 │   │  └──────┬──────┘ │
│ directory ◄──────── match the key  │   │         │        │
│      │ issues│   │  type per cert  │   │         ▼        │
│      ▼       │   │       │         │   │  F5       [x]    │
│  Certificate ───►│       ▼         │   │  nginx    [x]    │
│              │   │  Deploy ───────────►│  IIS      [x]    │
└──────────────┘   └─────────────────┘   └──────────────────┘
  one directory       one CNAME             deployed and
  per key type        delegation              verified

Both issuers share one set of credentials, and each ACME account persists after registration. Validation runs through one delegated CNAME per domain, so no DNS provider credentials are held anywhere.

CertKit has transformed how Belden manages SSL certificate issuance, delivering a streamlined process that dramatically reduced both cost and complexity. Their solution has been a clear win for our organization.

Ryan Buckner, IT Infrastructure Analyst, Belden

What CertKit handles

Register against SSL.com once per key type. The same Account/ACME Key and HMAC Key register both issuers, so there is no credential to maintain on any server.
Match every certificate to the right directory. ECC certificates go to the ECC issuer and RSA certificates to the RSA issuer, checked when you create the certificate rather than when an order fails.
Install the chain with the certificate. The intermediates that came with that certificate are deployed alongside it, so a renewal never leaves a stale chain behind.
Deploy to whatever terminates TLS. Load balancers, web servers, Windows services, and appliances, in each platform's format, including targets that can't run an ACME client at all.
Verify after every deployment. A TLS connection to the target confirming serial, names, and expiry match what was issued.
Alert on failure rather than on expiry. A renewal or deployment that didn't complete raises an alert while it's still fixable.
Keep a per-certificate history. Issuance, renewal, and install logged with timestamp and destination, across every issuer you run.

Setup takes about ten minutes

Delegate validation with one CNAME. A single record per domain, added once and reused by every renewal.
Copy your API credentials from SSL.com. Sign in to your SSL.com account, open the Dashboard, and choose api credentials under developers and integration.
Add SSL.com as an issuer in CertKit. Pick the ECC or RSA issuer, or add both with the same credentials. The Account/ACME Key is the EAB Key ID and the HMAC Key is the EAB HMAC. SSL.com decides which certificate type it issues, and bills your account for, from the names on each certificate.
Put the agent on each target. One install command per system, then choose that platform's deployment template.

See the issuer documentation →

Why not run ACME against SSL.com directly?

For one server with one key type, a standard ACME client pointed at the right SSL.com directory works fine. The trouble starts at the second host, the second key type, and the first appliance that can't run a client. Then you're maintaining clients, credentials, hooks, and a spreadsheet of which certificate lives where.

That is a certificate management system, and teams who start with a few scripts generally end up writing most of one. We wrote about why that happens. CertKit is that system, already built. SSL.com handles the issuance, CertKit handles everything downstream of it.

SSL.com is one issuer among several

CertKit issues from SSL.com alongside DigiCert, Sectigo, AWS Certificate Manager, and Let's Encrypt, and from a private CA for internal hostnames, IP address certificates, and mTLS client certificates that no public CA will sign. Monitoring covers every certificate regardless of which authority signed it.

See all integrations

Start automating SSL.com certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing