CA/Server configuration

[Dmitrii Odintcov]

Hello all

Thank you for your replies. They are all helpful in their different ways,
but have missed one particular point I was looking to clarify.

Suppose I have two private keys: one for a CA named 'foo', and one for a
server, 'bar'. I am using `req` to produce a CSR *from* bar *to* foo, and
then using `ca` to have foo generate a certificate *for* bar. Both of these
commands can accept the `-config` and `-extensions` arguments. It seems to
me that the two configs used would be answering the same abstract
questions, but from the different perspectives of a cert requestor and a
cert issuer:

   - Who am I (the requestor)? / Who am I (the issuer)?
   Presumably this is handled by distinguished_name.
   - What kind of certificate do I want? / What kind of certificate am I
   willing to issue?
   Handled by req_extensions and/or x509_extensions?
   - For how long do I want the certificate to be valid? / For how long am
   I willing to make the certificate valid?
   Handled by default_days.
   - etc.

This is where the confusion begins: if ‘bar’, the certificate requestor,
itself wants to be a CA (basicConstraints = CA:true), then its bar.conf
must answer *both* sets of questions at the same time! I don’t see how this
is possible when the same sections and parameter names are used.

For instance, if bar wants to request its own CA certificate to be valid
for 5 years, but is only willing to issue others’ certificates for 1 year,
what should `default_days` be in bar.conf? Generally, would bar’s `req`
section determine what bar itself wants to request, or how it processes the
requests of others? And since bar.conf has `basicConstraints = CA:true` to
request a CA certificate for itself, wouldn’t all the certificates it
issues also be CAs?

I fully expect my deductions above to be completely wrong because they
don’t make any sense, but I also do not understand how things *do* work,
and would greatly appreciate an explanation.


Best regards



On Fri, 30 Sept 2022 at 12:58, Michael Richardson <mcr at sandelman.ca> wrote:

>
> Cyprus Socialite <cyprussocialite at gmail.com> wrote:
>     > I am looking to clarify some conceptual and practical questions I've
>     > accumulated while trying to configure a private 'Root CA -
> Intermediate
>     > CA - Server' setup. Most of my confusion revolves around the
>
> Okay.
> (The word out there is "Intermediate CA" is a term best used in the
> context of
>  Bridge/Federation of CAs, and that the term "Subordinate CA" is preferred
> in
>  the original specifications.  I think you are creating a subordinate CA)
>
> I think that you have gone some distance and entered into questions which I
> have very little opinion, and maybe nobody else does other than to observe
> what choices others have made.
>
> Bob, Henk and I maintain two IETF internet-draft repos whose goal it is to
> act as a demonstration of build two-level ECDSA and EDDSA CA+subordinate.
> (We never intend to publish as RFC, but preferred ID format)
> They are at:
>    https://github.com/mcr/draft-moskowitz-ecdsa-pki-1
>    https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-10
>    https://github.com/rgmhtt/draft-moskowitz-eddsa-pki
>
>     > Secondly, how is the absence of a configuration
> field/section/extension
>     > handled? Does it default to some value (e.g. from
> /etc/ssl/openssl.cnf)
>
> It defaults to whatever openssl.cnf you have pointed to.
>
>     > or simply remain empty? For example, if I have no interest in OCSP
>     > functionality, is the non-provision of all of the related fields
> enough
>     > to prevent my certificates being declared invalid because CRL
> requests
>     > fail?
>
> yes.
>
>     > Thirdly, I would like to understand the difference between the
> 'digest'
>     > and the 'cipher' and what roles they perform in the communication
>     > process, especially in relation to the actual signing algorithm. As
> an
>     > aside: I've noticed that using any of the `sha3-*` digests somehow
>     > prevents Windows 10 from verifying my certificates.
>
> cipher would not be used in a CA.
> I would guess Windows10 does not support SHA3?
>
>     > Onto more practical concerns, I am thoroughly confused by how many
>     > OpenSSL tools seemingly perform the same tasks. For example, one can
>
> Yes, because the "openssl" tool is not really intended to be for
> production.
> It exists mostly to allow the libraries to be configured and tested.
> So, it evolved based upon the need of the day, not any master design.
>
> I've argued for splitting much of the higher-layer functions that it does
> into a different git repo, as the tool is too intimate with the libraries,
> and the continue to be things you can't (easily) do programatically, but
> the
> tools do.
>
>     > Finally, if anyone happens to be in possession of an exhaustive
>     > configuration file that includes *all* possible sections and fields
>     > supported by OpenSSL, I would very much appreciate a copy!
>
> Not me.
> A Xmas-Lights configuration would be interested to look at, but likely more
> confusing than useful.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221003/9bee2472/attachment.htm>