The idea and functionality looks good. Some quick friendly feedback:<p>For production I would want to run this in Docker in some sort of a portable fashion.<p>Looking at the documentation it seems that you have to manually enter the password when you start up step-ca. That's not really going to work for automated setups. You need to be able to inject secrets from environment variables, or these days, Kubernetes secrets.<p>There's also the issue of backing up your CA secrets, e.g. if your step-ca process dies and you want to restart it somewhere else. That may be out of scope for step-ca though and handled through some other process, which is fine.<p>Might be good to add some documentation on how to set this up in a high availability fashion so it is not a single point of failure.<p>I do like the relative simplicity of this compared to all the other CA solutions out there. Good luck and thanks for the work.
I feel like the lack of "audience" field (or equivalent) in AWS IID makes them bit less attractive for authentication than GCP/Azure ones. For example here step-ca could impersonate (if compromised) the client instance to any other services that were to use IID for auth (or vise versa).
This is very similar to [CFSSL](<a href="https://cfssl.org/" rel="nofollow">https://cfssl.org/</a>), any specific reasons to use this over Cloudflare's PKI?
This is very neat stuff and I'd actually be interested in talking to you more about where you see it going in the future, because it's extremely closely related to some stuff I've worked on. One clarification:<p>Am I understanding it correctly that step-ca can be configured to either 1) hand out certs for <i>any</i> CN or 2) only hand out certs for the machine's FQDN according to the instance metadata? In essence, the "any CN" mode is only useful for knowing that this instance is one of your own (but exactly which one is totally on the honor system), and the "FQDN only" mode is useful if you use your cloud provider's FQDNs for your hosts. Do I have that correct?
I've used XCA [1] before for managing my personal CA and PKI certs for things. I simply then share my root CA out to my necessary end points and handle things from there.<p>[1] <a href="https://hohnstaedt.de/xca/" rel="nofollow">https://hohnstaedt.de/xca/</a>
What's the advantage of this over some scripts like <a href="https://github.com/tomberek/easy-ca" rel="nofollow">https://github.com/tomberek/easy-ca</a>?