Ask for admin name/subject when creating creating first provisioner

[georgmu]

In enableAdmin=true mode, the first provisioner is created on startup.

This patch asks for the admin name/subject when creating the provisioner. This is necessary if the root CA has nameConstraints and only permits certain subjects.

Otherwise, there will be an error when using the provisioner with an admin command (e.g. step ca admin list). See #962

Name of feature:

Pain or issue this feature alleviates:

Fixes issue described in #962 if the root CA has name constraints

Why is this important to the project (if not answered above):

Is there documentation on how to use this feature? If so, where?

In what environments or workflows is this feature supported?

In what environments or workflows is this feature explicitly NOT supported (if any)?

Supporting links/other PRs/issues:

💔Thank you!

[CLAassistant]

All committers have signed the CLA.

[dopey]

Hey @georgmu thanks for opening the issue and associated PR. Totally agree that we need some way to change the first admin name to address this use case.

I don't love the idea of prompting for it, but I'm also not sure that there are better options.

@maraino of all the possible options I can think of, prompting may be the least bad.

Options:

• prompt in step-ca startup if first admin does not exist (this PR).
• allow option in ca.json for first admin name
• allow flag to step-ca for first admin name
• allow to set when calling step ca init --enable-admin --first-admin xxx

The problem with most of these is that if a value is not provided, we would default to step (assuming we didn't want to prompt) which would leave you stuck if that name wasn't allowed. Basically, we'd still need to prompt.

[maraino]

@dopey @georgmu: The proper fix is to add support for it in step ca init, but before that, we can have an --admin-subject flag in step-ca that sets the initial subject if we need to. We can also have an --admin-password-file to set a different password.

[dopey]

@maraino What would --admin-password-file do? The admin password is the provisioner password (assuming the provisioner is JWK). We can't set a different password for the admin unless we create a separate provisioner for the admin.

[dopey]

@georgmu do you think you could update this PR to use a flag (--admin-subject) rather than a prompt? I'll create an issue for the CLI to add an option to generate an admin on step ca init.

@maraino the only issue I foresee with using step ca init is that we don't currently do any database configuration in step ca init. We would need the DB connection string / password.

[hslatman]

One of the things I added in https://github.com/smallstep/certificates/pull/1075 and https://github.com/smallstep/cli/pull/758 is the ability to provide --admin-subject when doing step ca init. It'll work when initializing a CA with Remote Management enabled (--remote-management), because as part of that flow the first provisioner and admin are created in the DB immediately. It won't work when migrating to DB backed provisioners from config backed provisioners, as that's performed at CA startup. We would need to add the flag to that too, but that's not really nice.

[maraino]

@hslatman, if you think this PR is covered by #1075, feel free to close it.

[hslatman]

@maraino it partially addresses the issue, as it only works when initializing with --remote-management enabled.

When migrating from ca.json to DB backed provisioners, there's currently no option to provide the admin subject. Adding --admin-subject to the CA startup works, but is not really nice to do, IMO. Alternatively we could add a helper command that enables Remote Management, performs the migration and takes --admin-subject, but I doubt how often that will be used.

Besides one of the solutions above, we should probably add an (early) additional checks for the name constraints and policy configured to see if it would allows step or not and prevent from migrating if it isn't allowed.

[hslatman]

@dopey did you intentionally close this?

[dopey]

I did. There hasn't been any movement and I'm trynna clean up open pull requests that are just hanging around. If you think it should be reopened that's totally fine - I'll leave that up to you.

[hslatman]

Fine with it being closed. I think the migration is not done very often.