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@xxxxxxxxxxxx> wrote:
Cyprus Socialite <cyprussocialite@xxxxxxxxx> 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.
