Certs.d manpage & *.5.md suffix #594
Conversation
|
Ah, the base branch was wrong. Rebasing now. |
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1677264 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
vrothberg
force-pushed
the
certs.d-manpage
branch
from
7d00469
to
581fc2b
Compare
|
LGTM |
|
@TomSweeneyRedHat PTAL |
docs/containers-certs.d.5.md
Outdated
| ``` | ||
| $ openssl genrsa -out client.key 4096 | ||
| $ openssl req -new -x509 -text -key client.key -out client.cert | ||
| ``` |
There was a problem hiding this comment.
My only question is either of these examples valid to get a Container Registry up and running? The one that I cobbled together with @edsantiago 's help is:
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /root/auth/domain.key -x509 -days 2 -out /root/auth/domain.crt -subj "/C=US/ST=Foo/L=Bar/O=Red Hat, Inc./CN=localhost"
I don't know if that's entirely up to snuff, you'd definitely want to tweak the /root/auth and Red Hat, but I think it may be closer.
There was a problem hiding this comment.
They do the same, but your command generates the key in the call -newkey rsa:4096 and does not prompt the user to enter data such as country, province, organization, etc. as those are set in the subject.
There was a problem hiding this comment.
Neither of these is really likely to work: if the server is requiring client certificates, it can’t just accept any certificate any attacker can trivially generate like this!
An accepted certificate typically needs to be signed by a server-trusted CA (or, maybe better, a single-purpose CA created specifically for creating certificates accepted by that one server), and creating such a key+certificate pair is therefore somewhat CA-specific.
(Maybe for local testing one can get away with generating a single cert+key pair, and configuring the server to accept that single certificate (instead of a CA that signs other certificates); but that’s very helpful for any kind of production use.)
Overall I’d suggest removing this section completely.
There was a problem hiding this comment.
Overall I’d suggest removing this section completely.
done
docs/containers-certs.d.5.md
Outdated
| ``` | ||
| $ openssl genrsa -out client.key 4096 | ||
| $ openssl req -new -x509 -text -key client.key -out client.cert | ||
| ``` |
There was a problem hiding this comment.
Neither of these is really likely to work: if the server is requiring client certificates, it can’t just accept any certificate any attacker can trivially generate like this!
An accepted certificate typically needs to be signed by a server-trusted CA (or, maybe better, a single-purpose CA created specifically for creating certificates accepted by that one server), and creating such a key+certificate pair is therefore somewhat CA-specific.
(Maybe for local testing one can get away with generating a single cert+key pair, and configuring the server to accept that single certificate (instead of a CA that signs other certificates); but that’s very helpful for any kind of production use.)
Overall I’d suggest removing this section completely.
Suffix the manpages accordingly to be placed in the correct manpage folder during package installation. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
vrothberg
force-pushed
the
certs.d-manpage
branch
from
581fc2b
to
be91505
Compare
|
Updated. @mtrmac, can you have another look? |
|
LGTM. Thanks! |
Catching up with be91505 (docs: rename manpages to *.5.md, 2019-03-01, containers#594). Generated with: $ sed -i 's/policy.json.md/containers-policy.json.5.md/g' $(git grep -l policy.json.md)
Catching up with be91505 (docs: rename manpages to *.5.md, 2019-03-01, containers#594). Generated with: $ sed -i 's/policy.json.md/containers-policy.json.5.md/g' $(git grep -l policy.json.md) Looking to carry this over the finish line for Wking. Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@mtrmac @rhatdan @TomSweeneyRedHat PTAL
Context: https://bugzilla.redhat.com/show_bug.cgi?id=1677264