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 <m...@sandelman.ca> wrote: > > Cyprus Socialite <cyprussocial...@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. > >