Run your own private CA & ACME server using step-ca
With today’s release (v0.13.0), you can now use ACME to get certificates from step-ca. ACME (RFC8555) is the protocol that Let’s Encrypt uses to automate certificate management for websites. ACME radically simplifies the deployment of TLS and HTTPS by letting you obtain certificates automatically, without human interaction.
If you’re not using SSH certificates you’re doing SSH wrong
SSH has some pretty gnarly issues when it comes to usability, operability, and security. The good news is this is all easy to fix. SSH is ubiquitous. It’s the de-facto solution for remote administration of *nix systems. SSH certificate authentication makes SSH easier to use, easier to operate, and more secure.
Embarrassingly easy private certificate management for VMs on AWS, GCP, and Azure
step and step-ca (v0.11.0) adds support for cloud instance identity documents (IIDs), making it embarrassingly easy to get certificates to workloads running on public cloud virtual machines (VMs). This post introduces IID-based authentication with step and step-ca, and notes some interesting architectural and security details.
Good certificates die young: what's passive revocation and how's it implemented?
If you’re a normal human person you probably don’t think much about certificate revocation. This post will help you justify your apathy. It will explain why your indifference is, in fact, the technically correct attitude to have regarding this particular detail of your system’s security architecture.
Introducing step Certificates, secure, automated certificate management
Introducing step Certificates, an open-source project that makes secure automated certificate management easy, so you can use TLS and easily access anything, running anywhere, from everywhere. But step certificates is more than a certificate authority. It provides all the missing bits you need to run your own internal public key infrastructure (PKI).
Everything you should know about certificates and PKI but are too afraid to ask
Certificates and public key infrastructure (PKI) are hard. No shit, right? I know a lot of smart people who’ve avoided this particular rabbit hole. Eventually, I was forced to learn this stuff because of what it enables: PKI lets you define a system cryptographically. It’s universal and vendor-neutral yet poorly documented. This is the missing manual.
The case for using TLS everywhere

The case for using TLS everywhere

By: Mike Malone

This post has a simple purpose: to persuade you to use TLS everywhere. By everywhere, I mean everywhere. Not just for the public internet, but for every internal service-to-service request. Not just between clouds or regions. Everywhere. Even inside production perimeters like VPCs. I suspect this will elicit a range of reactions from apathy to animosity. Regardless, read on.
Step: A New Zero Trust Swiss Army Knife from Smallstep
A better security model exists. Instead of relying on IP and MAC addresses to determine access we can cryptographically authenticate the identity of people and software making requests. It’s a simple concept, really: what matters is who or what is making a request, not where a request comes from. In short, access should be based on production identity.