CA/Server configuration

[Michael Richardson]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220930/104e3068/attachment.sig>