← Integrations

GlobalSign Atlas ACME automation and deployment

GlobalSign automates issuance. Everything downstream of it is still manual.

GlobalSign Atlas is built for issuing certificates at volume through an API, and its ACME support means a standard client can request certificates against your account with External Account Binding credentials. That covers getting certificates. It does not cover getting them onto the load balancers, web servers, and appliances that present them, which is the work that actually repeats twelve times a year once lifetimes compress toward 47 days.

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

Start free trial Watch demo

What GlobalSign ACME still leaves on your plate

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

  1. Register every client, each with its own MAC key. A MAC key authorizes one ACME account registration and expires after 30 days. One client is trivial. A fleet means minting one before each registration, and any host you rebuild later needs another.
  2. Install and maintain a client per host. The usual rollout, version drift, and per-machine configuration.
  3. Ship the full chain, every time. A hook that writes only the leaf, or that hardcodes an intermediate copied from an older certificate, produces something that validates in a desktop browser and fails for API clients and mobile apps.
  4. Write the post-deploy hooks. Convert, place, reference, reload, once per platform, run only at renewal.
  5. Cover the appliances. Load balancers and gateways import certificates through an API. No ACME client does that.
  6. Add monitoring and an audit record. Verification that the new certificate is actually being served, and a durable log of which certificate went where. Neither is part of an ACME client's job.

Atlas exists precisely because issuance at volume needs automating, and it solves that half convincingly. 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.

At 47-day lifetimes, deployment becomes a permanent workload. Here's how CertKit carries it for your GlobalSign estate.

How it works

   GlobalSign             CertKit              Your systems
┌──────────────┐   ┌─────────────────┐   ┌──────────────────┐
│   Atlas      │   │  register once  │   │                  │
│  ACME  ◄─────────── with API key   │   │  ┌─────────────┐ │
│              │   │  + MAC key      │   │  │CertKit Agent│ │
│      │ issues│   │                 │   │  └──────┬──────┘ │
│      ▼       │   │  MAC key not    │   │         │        │
│  Certificate ───►│  needed again   │   │         ▼        │
│              │   │       │         │   │  F5       [x]    │
│              │   │       ▼         │   │  nginx    [x]    │
│              │   │  Deploy ───────────►│  IIS      [x]    │
└──────────────┘   └─────────────────┘   └──────────────────┘
   high-volume        one CNAME             deployed and
   issuance API       delegation              verified

After registration the ACME account persists, so the 30-day MAC key expiry never touches renewals. 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

Setup takes about ten minutes

  1. Delegate validation with one CNAME. A single record per domain, added once and reused by every renewal.
  2. Generate a fresh MAC key in Atlas. Sign in to GlobalSign Atlas, open your API credential, and generate a MAC Key. Do this immediately before the next step, since it expires after 30 days.
  3. Add GlobalSign as an issuer in CertKit. The API Key is the EAB Key ID and the MAC Key is the EAB HMAC. Add a name and contact address, and the issuer is live once it registers.
  4. Put the agent on each target. One install command per system, then choose that platform's deployment template.

See the issuer documentation →

Why not build against the Atlas API directly?

Atlas has a capable API and if you are issuing certificates programmatically as part of a platform you are building, using it directly is a reasonable choice. The question is what you end up owning: the issuance calls are the small part, and the retry logic, the inventory, the deployment to each platform, the verification, and the alerting are the rest of it.

That is a certificate management system, and teams who set out to write a thin wrapper around a CA API generally discover they have written most of one. We wrote about why that happens.

CertKit is that system, already built. Atlas handles the issuance, CertKit handles everything downstream of it, and the integration is configuration rather than code you have to maintain.

GlobalSign is one issuer among several

CertKit issues from GlobalSign alongside Actalis, Sectigo, DigiCert, 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 GlobalSign 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