False successful response when POST to `api/v1/cfssl/newcert`
- Dominant language
- Go
- Stars
- 9.5k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
The issue occured for me on this particular endpoint, maybe it is relevant to other endpoints too, but I haven't checked that.
I am implementing service, that communicates with `cfssl` server in order to generate pair of certificate and private key. To do so, my service sends `POST` request to `api/v1/cfssl/newcert` with following body:
```json
{
"request": {
"CN": "some-common-name",
"hosts": [ ],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [ ]
}
}
```
In such case everything works fine, however, recently I've refactored piece of code in my service that was requesting those certificates. Unfortunately, I've missused library that manipulate json objects, and when my service was modifying template from above, it was also unintentionally removing root key - "request", so the body would look like this:
```json
{
"CN": "some-common-name",
"hosts": [ ],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [ ]
}
```
It is still valid json in terms of grammar, it is also valid for `cfssl` in a way that it's not returning any errors - all the mandatory keys are still present, the only warning being returned says that "hosts" are empty - that's fine for me.
However, `cfssl` doesn't warn about the fact, that this whole body holding important params is simply ignored - when json is missing "request" key, `cfssl` behalfs like it was using some sort of default template, because it's generating `ecdsa` key and it's ignoring common name. Even if it's expected behaviour, it would be nice to somehow warn about this, I've spent quite a while troubleshooting 🙄.
Contributor guide
Research direction
Start at the api/v1/cfssl/newcert handler and trace how a POST body is decoded when the root "request" key is missing. Reproduce the request with the JSON shown in the issue, then verify that the endpoint warns or rejects the ignored certificate parameters while preserving valid handling of the expected request shape.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100