"Cert request rejected" when NumberSignersRequired < 0, but cert is still signed and valid

OmarDarwish commented 7 years ago

I enabled auto signing for an environment as follows:

{
  "myEnv": {
    "AuthorizedSigners": {
      "<redacted>": "omar.darwish"
    },
    "AuthorizedUsers": {
      "<redacted>": "omar.darwish"
    },
    "NumberSignersRequired": -1,
    "MaxCertLifetime": 86400,
    "PrivateKeyFile": "/path/to/key.rsa"
  }
}

I request certificates for this environment like so:

$ ssh-cert-authority request --principals myUser --environment myEnv --reason "debugging myEnv" --valid-before "1h59m0s"

Which returns Cert request rejected: FPRMTRTVURB54QAV.

This is incorrect because if I attempt to sign the same ID, it reports that Certificate already signed. Thanks for trying.

I can also get this certificate using the same Id. It is a valid certificate which has the same expiration I set above, so it clearly is accepting my request, signing it, and is able to generate a certificate.

bobveznat commented 7 years ago

Just to be clear, in this case everything is working exactly how it is supposed to but the error message from the request command is wrong?

I can see that in an environment I have the client is behaving correctly (I wish it auto-downloaded the signed cert but that's a future enhancement).

Can you also share with me the logs from the daemon? And it appears you don't have the Slack integration enabled, is that true?

OmarDarwish commented 7 years ago

Just to be clear, in this case everything is working exactly how it is supposed to but the error message from the request command is wrong?

Yes, correct. Everything is working as intended, except for the incorrect message.

Here's are the client commands that were run:

$ ssh-cert-authority request --principals myUser --environment myEnv --reason "debugging myEnv" --valid-before "1h59m0s"

Cert request rejected: VJDFUSGID5YPAHBI

$ ssh-cert-authority get --environment myEnv VJDFUSGID5YPAHBI

Certificate data:
  Serial: 151
  Key id: omar
  Principals: [centos]
  Options:
  Permissions:
      permit-agent-forwarding:
      permit-port-forwarding:
      permit-pty:
  Valid for public key: eb:d2:50:ce:ad:de:d8:27:3e:dd:16:42:b8:e1:51:33
  Valid from 2016-12-05 12:58:39 -0500 EST - 2016-12-05 15:00:39 -0500 EST
Identity added: /Users/omar/.ssh/id_rsa (/Users/omar/.ssh/id_rsa)
Lifetime set to 6999 seconds
Certificate added: /Users/omar/.ssh/id_rsa-cert.pub (omar)
Lifetime set to 6999 seconds

Here are the relevant daemon logs:

Dec 05 18:00:39 ssh-cert-authority ssh-agent[26676]: 2016/12/05 18:00:39 Received 0 signatures for VJDFUSGID5YPAHBI, signing now.
Dec 05 18:00:39 ssh-cert-authority ssh-agent[26676]: 2016/12/05 18:00:39 Cert request serial 151 id VJDFUSGID5YPAHBI env myEnv from b4:f1:89:6f:5e:b8:70:94:32:5f:70:ac:bb:aa:48:e8 () @ 127.0.0.1:33955 principals [centos] valid from 1480960719 to 1480968039 for 'debug'

I'm new to discussions on git, so I'm not sure which Slack plugin you're referring to 😁

bobveznat commented 7 years ago

The slack plugin is builtin to ssh-cert-authority. You can configure it to post to a slack channel whenever someone requests or +1s a cert. I ask because if Slack is enabled that's one more failure scenario for me to wander through.

I've been trying to figure out how this can be happening and I don't have many theories. My best one is that your client, the thing doing the requesting, is old. If your client were older than November of 2015 (yes, a year ago) then you'd definitely have the client report that the request was rejected because the HTTP status code sent back by the API was 202 and the client only understood 201 at that point.

Any chance you have a really old client? In the mean time I'll keep poking around.

OmarDarwish commented 7 years ago

That seems to have been the issue! We were running client version 1.0.0, but the server was running revision 38. Thanks!

bobveznat commented 7 years ago

cloudtools / ssh-cert-authority

"Cert request rejected" when NumberSignersRequired < 0, but cert is still signed and valid #24