alpinCertificateTool

How it fits together

Every server that needs an SSL certificate runs one small updater script, alpinCertificateClient. That script talks to the alpinCertificateTool REST API, hosted in our cloud environment. The platform holds a securely encrypted store of client credentials and certificates, and it bundles the entire software stack needed to talk to Certificate Authorities — currently Let's Encrypt, in both its production and sandbox (staging) environments — as well as connectors to DNS provider APIs, currently AWS Route 53 and Cloudflare DNS, used to automatically satisfy DNS-based domain authorization.

You also get access to the alpin-cert-tool d.3one app from your d.3one Configuration Dashboard. It shares the same encrypted storage as the main platform, and lets you inspect the audit logs for your accounts, domains, and certificates, and create, display, or destroy your user keypairs.

The zero-knowledge approach

alpinCertificateTool follows a zero-knowledge security model: every piece of sensitive information stored on our platform — user account private and public keys, and certificate private and public keys — is encrypted with a security key that we never know and never store anywhere. Only the client, using alpinCertificateClient, chooses that key and passes it along with each call.

This means we can guarantee that nobody — not even us — can issue or renew certificates on your behalf. Only you, knowing your own security key, can do that. The one and only responsibility this places on you is safekeeping that key. Losing it is equivalent to losing every Certificate Authority account and certificate you've issued through the platform: you would need to create new accounts and new certificates under a new key.

Why this matters for you

Because of this model, you never have to do the heavy lifting normally involved in SSL certificate management:

• Handling user accounts and their private/public keys for one or more Certificate Authorities
• Managing private/public keys for one or more SSL certificates at the Certificate Authority
• Tracking renewal deadlines
• Managing the DNS authorization flows required by the ACME protocol

All of this is handled transparently by the alpinCertificateTool platform.

Authorizing certificate issuance

Before a Certificate Authority issues a certificate, it needs proof that you actually control the domain the certificate is for. The ACME protocol supports several ways to prove this, and alpinCertificateTool supports the following:

• HTTP-01 — the server requesting the certificate must be publicly reachable on the internet. During issuance, the CA emits a challenge token that must be published on that server. It's simple to implement, but unusable for private servers that need an SSL certificate without being reachable from the internet.
• DNS-01 — the client creates a specific TXT record (_acme-challenge.<your-domain>) in its DNS zone, letting the CA verify domain control via DNS queries. This is one of the challenge types alpinCertificateTool supports, with a caveat:
  • With a DNS provider that has no API access, you'd need to manually enter the updated TXT record on every renewal — cumbersome, and it breaks the "runs by itself every night" promise of the updater script.
  • With a DNS provider that does support API access, alpinCertificateTool can create, verify, and clean up the TXT record automatically. We currently support AWS Route 53 and Cloudflare DNS, and can add further API-driven providers on request.
• DNS-PERSIST-01 — instead of updating the TXT record on every renewal, you create it once, and as long as it exists, the CA can keep issuing certificates for that domain. alpinCertificateTool already supports this challenge type, but it's still an IETF work in progress, not yet finalized — so it isn't intended for production use yet. We expect it to become generally available later in 2026 (targeted for Q3–Q4).
• DNS-HOSTED-01 — a proprietary alpinCertificateTool challenge type that solves the shortcomings of the two above: DNS-01 isn't very convenient without an API-first DNS provider, and DNS-PERSIST-01 isn't finalized yet. With DNS-HOSTED-01 you create a single CNAME record, once, pointing to alpinCertificateTool's own DNS infrastructure. From then on, we automatically create, update, and delete the DNS records needed for the ACME handshake on our side of that delegation — no further DNS changes required on yours. This is the option of real added value if you don't have an API-first DNS provider like Route 53 or Cloudflare.

The end-to-end workflow

1. Get API access. You receive an API account and key for the alpinCertificateTool platform when you subscribe to the service.
2. Install the client. Deploy alpinCertificateClient on every server where certificates should be managed and installed automatically.
3. Choose your zero-knowledge key. Generate and securely store the private security key described above — only you know it, and you pass it on every call.
4. Create a Certificate Authority account. Using the client, register an account with one or more Certificate Authorities; we handle key generation and encryption under your zero-knowledge key.
5. Issue or renew certificates. Using the client, request a new or renewed certificate; we generate and protect its key pair, and return the valid certificate to the client that requested it.
6. Install it. The client installs the certificate on your target systems — Apache, nginx, IIS, the Windows certificate store, or d.velop application components.

Installing certificates on your systems

To make step 6 painless, alpinCertificateClient ships with:

• A helper that checks how many days of validity remain on the current certificate, and only kicks off renewal once fewer than a configurable number of days are left
• Sample installation scripts for common targets — Apache, nginx, Tomcat, Windows IIS, the Windows certificate store, and d.velop applications — that you enable or comment out as needed
• Guidance on scheduling the script to run automatically every night

See the Client Documentation page for the full configuration reference and use cases.