Automate Server and Infrastructure Certificates with Ansible and Dynamic PKI

Eliminate manual certificate management for servers, services, and infrastructure. SecureW2 issues and renews certificates automatically via ACME and SCEP, enforcing enrollment policy at issuance so every certificate is bound to a verified identity before it reaches your infrastructure.

Schedule a demoContact Sales

Overview

Automate Device Compliance via Cloud-Native Certificate Lifecycles

SecureW2’s integration with Ansible automates X.509 certificate management for servers and infrastructure, replacing manual processes with policy-driven automation. Certificates are issued via ACME or SCEP from SecureW2’s Dynamic PKI, validated against enrollment policies. Ansible handles infrastructure management, while SecureW2 enforces enrollment, issues certificates, tracks lifecycle, and renews them automatically. This coordination ensures certificates are issued only to verified workloads, never expired silently, or manually renewed, bridging infrastructure automation and certificate management.

Use Cases
Workload Identity and mTLS Between Services
Server Certificate Automation via ACME

How It Works

From Certificate Request to Automated Lifecycle

Certificate Issuance Flow ACME

SecureW2’s ACME endpoints automate certificate issuance for servers and workloads using External Account Binding to ensure only authorized systems can enroll. Certificates are issued, renewed, and suspended automatically or by admin decision through any ACME-compatible client, eliminating manual provisioning for dev and IT teams without requiring custom tooling.

REST API Certificate Enrollment

SecureW2’s REST APIs give automation tooling full programmatic control over certificate enrollment for non-human identity servers, IoT devices, and containers, with certificate types and lifespans configurable per workload or team through policy. Enrollment is triggered directly by the pipeline at deployment time, so certificate issuance becomes a step in the automation process rather than a separate manual workflow.

Use Cases

Deployment & Architecture Detail

Workload Identity and mTLS Between Services

Service-to-service communication in microservice environments needs verifiable identity, not just network trust. Mutual TLS (mTLS) demands both client and server present certificates from a trusted CA before data exchange. SecureW2 acts as this CA, issuing certificates with verified workload identities. During connection, services verify certificates against the SecureW2 root. If a certificate is expired, revoked, or untrusted, the handshake rejects the connection automatically. 

Server Certificate Automation via ACME

Manual certificate management—tracking expiry, submitting CSRs, and installing certificates manually—causes operational risk, with certificates expiring unexpectedly, audit issues, and emergency maintenance. ACME automates issuance and renewal directly from infrastructure. SecureW2 is the ACME authority; servers request certificates via their ACME client (cert-manager, acme.sh, Certbot, native tools) pointing to SecureW2. Requests are validated against enrollment policies before signing, with certificates issued containing the validated server identity in the SAN and automatically renewed before expiry. Policy controls include allowed domains, SANs, key types, sizes, maximum lifetime, and requester verification; any non-compliant request is rejected.

Frequently Asked Questions

Ansible Integration — Common Questions

Does SecureW2 replace Ansible's existing PKI or work alongside it?

SecureW2 can act as the sole certificate authority for infrastructure certificates or operate alongside an existing internal CA as a subordinate or parallel issuer. For organizations already using Ansible for secrets management or configuration management, SecureW2 replaces the manual certificate issuance step; Ansible continues to manage distribution and storage, while SecureW2 handles the PKI layer.

What ACME clients are compatible with the SecureW2 ACME endpoint?

SecureW2's ACME endpoint is compatible with any RFC 8555-compliant ACME client, including cert-manager (Kubernetes), acme.sh, Certbot, and native ACME support in tools like Caddy and Traefik. SCEP is also supported in environments where ACME is unavailable, including legacy infrastructure and Windows-based servers.

How are certificate renewal attempts handled if the renewal policy check fails?

If a renewal request fails the Policy Engine enrollment check, for example, because the workload is no longer registered, the domain is no longer authorized, or the requesting identity has changed, the renewal is rejected, and the existing certificate is not replaced. SecureW2 alerts on the failure before the existing certificate expires, allowing time for investigation and manual remediation without an outage.
 

Can SecureW2 issue certificates for internal hostnames and private IPs?

Yes. SecureW2 Dynamic PKI is an internal CA that can issue certificates for any hostname, internal domain, or IP address that the enrollment policy authorizes including RFC 1918 private addresses and .internal or .local domains. SecureW2 does not require public CA validation. The CA root is distributed to trusting systems through the normal CA trust anchor distribution process.

Does this integration support short-lived certificates for workload identity?

Yes. SecureW2 Dynamic PKI supports certificate lifetimes from minutes to years, configurable per enrollment policy. For workload identity use cases such as service mesh mTLS or ephemeral CI/CD identities short-lived certificates (minutes to hours) eliminate the need for a CRL or OCSP check at connection time, since a certificate that expires in 60 minutes is effectively self-revoking. ACME clients renew automatically when the lifetime drops below the renewal threshold.

What certificate attributes can be embedded in issued certificates?

SecureW2 can embed any standard X.509 attributes in the Subject and Subject Alternative Name (SAN) fields, including DNS names, IP SANs, URI SANs, and email addresses. For workload identity certificates, the SAN is typically populated with the verified workload identity (service account, hostname, or URI) passed in the ACME or SCEP request and validated against the enrollment policy.

How does certificate revocation work for server and service certificates?

SecureW2 maintains a CRL (Certificate Revocation List) and OCSP responder for all issued certificates. Certificates can be revoked individually through the SecureW2 management portal or API. For short-lived workload identity certificates, revocation is typically handled by not renewing the certificate expires before revocation propagation becomes relevant. For longer-lived server certificates, CRL and OCSP distribution points are embedded in the issued certificate.

How is Ansible configured to request certificates from SecureW2?

Ansible-specific configuration answer — e.g., for Vault: PKI secrets engine backed by SecureW2 ACME; for cert-manager: ClusterIssuer pointing to SecureW2 ACME endpoint; for Ansible: role variables for SCEP endpoint and challenge password; for Jenkins: Certificate plugin configuration with SecureW2 CA URL. 

Ready to Connect Ansible to SecureW2?

Connect with our integration specialists to implement this solution in your environment and transform your security posture.

Schedule a demoContact Sales
Reseller or MSP? Join our Partner Program