@sarge Just so you know, I am following your updates, I just have been very busy with some other things right now.
Allow me to paste in some tips from the Smallstep team on our Slack a while back, it may be helpful!
Mariano:
The pki
package is used to create the configuration for the ca, in your case you will only need to use GenerateRootCertificate
and GenerateIntermediateCertificate
.
These methods, are just helpers over x509util package - github.com/smallstep/cli/crypto/x509util - Go Packages, you can also use pemutil package - github.com/smallstep/cli/crypto/pemutil - Go Packages (pemutil.Serialize()
) to store the pem files if your disk, encrypted or not.
If you look into the code you will see two different x509
packages, one that we usually call stepx509
that is embedded in cli/pkg/x509
. This one is likely to go away soon as Go 1.13 already supports Ed25519, and we want to enforce this version. Note that the pki
package is going to change and the constructor for the new version won’t accept any parameters.Then for the ACME part, if you’re using step-ca for this, all the handlers are in api package - github.com/smallstep/certificates/acme/api - Go Packages. They use a special authority acme package - github.com/smallstep/certificates/acme - Go Packages on top of the main one certificates/authority
that is used to sign certificates.
Currently, the only way to build the authority authority package - github.com/smallstep/certificates/authority - Go Packages is using a Config
struct, and this should have at least the path for the root certificate, intermediate certificate and key, at least one acme provisioner and a DNSName to create the actual server certificate, other properties might also be required but they are not that important. Right now the main authority enforces encryption in the intermediate key, but you can set the password in the config.
At some point, sooner than later, we want to change the authority constructor not require all that, and you can set up your own signers just passing variadic parameters, the configuration will be an extra one, that sets up everything from a Config struct or file. Imagine something like authority.New("localhost", authority. WithTLSSigner(mySigner))
One thing more, the acme requires a db, by default step-ca will use a local badger db, but you can always build an interface if you want to store it in memory: database package - github.com/smallstep/nosql/database - Go Packages
Trusting the development CA could be done with this, I think: GitHub - smallstep/truststore: Package to locally install development certificates
Then, a few of my own thoughts in response to you @sarge:
I am hoping that we do not need to expose the “smallstep” brand/name in the config, as that seems like an implementation detail. Rather, I think what the user really would want to configure is whether a site/domain gets TLS. For local/internal names, it should get them from smallstep under the hood; for public sites, it should use a public CA. I think it’s that straightforward: it’s just a matter of deciding this automatically and exposing the right config to the user for choosing whether to use an internal or public CA. If they want to use an internal or local one, it should be smallstep by default, but of course they could configure this.
I think the point is that we do want to run an actual, self-contained, internal CA for non-public names. So I still think smallstep is the right way to go here.
We don’t have to make the user configure every detail – in the simplest form, they should only choose whether to use a local, internal, or public CA for certs, and only if we can’t determine it automatically. Does that make sense?