Allow empty or absent subject block
#209
Conversation
…_request` and `tls_self_signed_cert`
The only case to handle are: 1. is absent 2. is empty in case it appear multiple times instead, we let the schema handle that
detro
force-pushed
the
detro/61-allow_empty_or_absent_subject_block
branch
from
2d74b4c to
dcc3328
Compare
….1.2.6 If the certificate we are creating is a CA, subject can't be empty
…ng a CA that is not a CA The certificate will STILL be created, but the provider should signal that the resulting certificate could fail validation.
…ert` resource when providing a CA that is not a CA
| @@ -8,6 +8,7 @@ install: build | |||
|
|
|||
| # See https://golangci-lint.run/ | |||
| lint: | |||
| golangci-lint cache clean | |||
There was a problem hiding this comment.
Interesting, I've never needed to run this before. Is there something going on that requires it?
There was a problem hiding this comment.
I haven't experienced this before, but I have had a situation with the unparam linter where it wouldn't pick up an issue until I cleaned the cache.
I might be something that can only happen locally, as the runners on the GH CI are always executed against a fresh environment.
I'm not sure it's necessary, but it did seem to make a difference in spotting this. 🤷
Co-authored-by: Brian Flad <bflad417@gmail.com>
* Update schema to allow `subject` to be optional or empty in `tls_cert_request` and `tls_self_signed_cert` * Centralised the logic to handle `subject` detection and parsing The only case to handle are: 1. is absent 2. is empty in case it appear multiple times instead, we let the schema handle that * Updated testing * Regenerated doc * Linter caught issues * Updated CHANGELOG * Tweaking negative tests error regexp to accomodate TF 0.12 * Better follow https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6 If the certificate we are creating is a CA, subject can't be empty * Raise a warning when trying to create a `tls_locally_signed_cert` using a CA that is not a CA The certificate will STILL be created, but the provider should signal that the resulting certificate could fail validation. * PR review * Parallelise run for GolangCI-Lint(er) * Update CHANGELOG: mention warning now raised by `tls_locally_signed_cert` resource when providing a CA that is not a CA * Apply suggestions from code review Co-authored-by: Brian Flad <bflad417@gmail.com> Co-authored-by: Brian Flad <bflad417@gmail.com>
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes #61
RFC that motivates fixing this bug: https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6
This affects 2 resources:
tls_cert_requesttls_self_signed_certCaveat
In accordance with RFC 5280, the creation of the certificate will
fail, if the desired certificate is a CA and it has an empty Subject (i.e. no Distinguished Name is provided). Specifically, this part of the RFC:
Small side improvement
Something that is possible to do with
tls_locally_signed_cert, but it's probably undesirable, is to create a certificate using as CA a certificate that, in facts, is not one.As this if functionally legit, now we will just raise a warning every time a certificate with this "quirk" gets created with this resource.