Environment requirement for signing/fetching

[micahlmartin]

When you do request_cert --environment dev this generates a unique ID which I assume is specific to that environment/request. I would assume that I should be able to do sign_cert <ID> and be able to drop the --environment dev from the command but this is not the case. What's interesting is that I can do sign_cert --environment other <ID> and it works. I think the requirement of --environment should be dropped altogether for the sign_cert and request_cert operations.

Thoughts?

[bobveznat]

The --environment other workaround is what I do as well. I have shell scripts like "request_cert_prod" and "request_cert_stage" but for signing I call the script "sign_cert".

The one use case that requiring an env supports today is multiple servers. If you had multiple environments spread across multiple servers (e.g. prod on server a and stage on server b). However, I know of exactly zero users of ssh-cert-authority that have multiple environments distributed across multiple servers .

The same issue extends to get cert as well.

I think this is good feedback. While the workaround is pretty simple and is "set it and forget it" I may as well patch this up.

I'll leave this issue open and plan to fix it.

[mvdkleijn]

Maybe another option is to simply have a default value for the environment option for those that don't want to use it?

[bobveznat]

If your configuration file only contains one environment the code is smart enough to not require the --environment flag. But when more than one environment is in the configuration file it throws its hands up in the air and makes the user choose.

In my workplace we have 5 ssh-cert-authority environments. So I have 5 scripts like these (stage, prod, yeti shared, yeti stage and yeti prod):

$ cat /usr/local/bin/request_cert_stage

!/bin/bash

/usr/local/bin//ssh-cert-authority request --environment stage $@

[mvdkleijn]

Cool, I didn't realize it did that. That would totally solve my issue, thanks for the info. :smile: