تخطي إلى المحتوى الرئيسي
Microsoft
separator
https://catalogartifact.azureedge.net/publicartifacts/lynxroute.step-ca-9a9a4de7-e6e9-4282-83e8-1e779c211ecb/image3_Azureready.png

Step-ca - Hardened Private Certificate Authority

بواسطة Lynxroute

step-ca 0.30.2 - CIS Level 1 hardened private CA and ACME server on Ubuntu 24.04, SBOM + CIS

What is step-ca

step-ca is an online private certificate authority from Smallstep. It issues short-lived X.509 certificates for your internal services over its own API and over ACME, the same protocol your existing tooling already speaks. Any standard ACME client works against it, including Certbot, acme.sh, lego, Caddy, Traefik and cert-manager, so you can automate internal TLS the same way you automate public TLS. It also supports the JWK provisioner for token-based issuance, certificate renewal over mutual TLS, and revocation. State lives in an embedded key-value store, so there is no database server to run, patch or back up separately.

Why self-host step-ca

Public certificate authorities will not issue certificates for internal host names, private IP addresses or service-mesh identities. Running your own CA lets you put real TLS on everything inside your network, on names you choose, with lifetimes you choose. The root key stays on infrastructure you control and can be moved offline entirely. There are no per-certificate fees, so issuing a certificate to every service, container and device costs nothing beyond the VM.

What this VM image adds

Security hardening:

  • Your CA keys are yours alone - the root and intermediate keys, and the passwords protecting them, are generated on your instance at first boot. Nothing is baked into the image, so no two deployments share a certificate authority
  • Password-protected issuance - the JWK provisioner is locked with a 24-character random password generated per instance
  • Bounded certificate lifetime - certificates issued over ACME are capped at 24 hours, which keeps renewal automated and limits exposure
  • No management API exposed - remote provisioner management is switched off, so the CA serves issuance endpoints only
  • TLS only - no plaintext listener is configured; TLS 1.2 is the floor, renegotiation is off
  • Sandboxed service - runs as a dedicated non-root user under a read-only filesystem namespace, with writes limited to its database and log, and only the one capability it needs to bind port 443
  • CVE scan - every image is scanned for vulnerabilities with Trivy before release
  • UFW firewall - inbound limited to SSH on 22 and the CA API on 443
  • fail2ban - SSH brute-force protection
  • AppArmor - mandatory access control

OS hardening (CIS Level 1):

  • CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
  • auditd - system call auditing for critical paths
  • SSH hardening - PasswordAuthentication disabled, key-only access
  • Kernel hardening - SYN cookies, ASLR, rp_filter, TCP BBR
  • /tmp as tmpfs - nosuid, nodev, noexec
  • Azure IMDS endpoints - egress rules pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

  • SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
  • CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
  • Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
  • Root certificate in the OS trust store - your new CA is trusted on the instance itself from first boot

Quick Start

  1. Deploy the VM (Standard_D2s_v3 or larger recommended)
  2. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
  3. Read the handout: sudo cat /root/step-ca-credentials.txt - it contains the CA URL, the root fingerprint, the provisioner password and the ACME directory URL
  4. Trust the CA from a client machine: step ca bootstrap --ca-url https://<PUBLIC_IP> --fingerprint <fingerprint> --install
  5. Issue a certificate: step ca certificate myservice.internal myservice.crt myservice.key, or point any ACME client at the directory URL

Before you open port 443 beyond your own networks: ACME issuance is not individually authenticated, so anything able to reach the CA can request a certificate from it. Restrict inbound 443 to the networks allowed to enrol, or remove the ACME provisioner with the single command given in the credentials file. Certificate requests through the JWK provisioner always require the password.

العربية (ليبيا)
أيقونة إلغاء الاشتراك في اختيارات خصوصيتك خيارات خصوصيتك
خصوصية صحة المستهلك خريطة الموقع اتصل بنا الخصوصية وملفات تعريف الارتباط شروط الاستخدام العلامات التجارية حول إعلاناتنا إدارة ملفات تعريف الارتباط