<div dir="ltr">Hello all<div><br></div><div>Thank you for your replies. They are all helpful in their different ways, but have missed one particular point I was looking to clarify.<br></div><div><br></div><div>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 <i>from</i> bar <i>to</i> foo, and then using `ca` to have foo generate a certificate <i>for</i> 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:<br><ul><li>Who am I (the requestor)? / Who am I (the issuer)?<br>Presumably this is handled by distinguished_name.<br></li><li>What kind of certificate do I want? / What kind of certificate am I willing to issue?<br>Handled by req_extensions and/or x509_extensions?<br></li><li>For how long do I want the certificate to be valid? / For how long am I willing to make the certificate valid?<br>Handled by default_days.<br></li><li>etc.</li></ul><div>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 <i>both</i> sets of questions at the same time! I don’t see how this is possible when the same sections and parameter names are used.</div><div><br></div><div>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?</div><div><br></div><div>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 <i>do</i> work, and would greatly appreciate an explanation.<br></div><div><br></div><div><br></div><div>Best regards</div><div><br></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 30 Sept 2022 at 12:58, Michael Richardson <<a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Cyprus Socialite <<a href="mailto:cyprussocialite@gmail.com" target="_blank">cyprussocialite@gmail.com</a>> wrote:<br>
> I am looking to clarify some conceptual and practical questions I've<br>
> accumulated while trying to configure a private 'Root CA - Intermediate<br>
> CA - Server' setup. Most of my confusion revolves around the<br>
<br>
Okay.<br>
(The word out there is "Intermediate CA" is a term best used in the context of<br>
Bridge/Federation of CAs, and that the term "Subordinate CA" is preferred in<br>
the original specifications. I think you are creating a subordinate CA)<br>
<br>
I think that you have gone some distance and entered into questions which I<br>
have very little opinion, and maybe nobody else does other than to observe<br>
what choices others have made.<br>
<br>
Bob, Henk and I maintain two IETF internet-draft repos whose goal it is to<br>
act as a demonstration of build two-level ECDSA and EDDSA CA+subordinate.<br>
(We never intend to publish as RFC, but preferred ID format)<br>
They are at:<br>
<a href="https://github.com/mcr/draft-moskowitz-ecdsa-pki-1" rel="noreferrer" target="_blank">https://github.com/mcr/draft-moskowitz-ecdsa-pki-1</a><br>
<a href="https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-10" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-10</a><br>
<a href="https://github.com/rgmhtt/draft-moskowitz-eddsa-pki" rel="noreferrer" target="_blank">https://github.com/rgmhtt/draft-moskowitz-eddsa-pki</a><br>
<br>
> Secondly, how is the absence of a configuration field/section/extension<br>
> handled? Does it default to some value (e.g. from /etc/ssl/openssl.cnf)<br>
<br>
It defaults to whatever openssl.cnf you have pointed to.<br>
<br>
> or simply remain empty? For example, if I have no interest in OCSP<br>
> functionality, is the non-provision of all of the related fields enough<br>
> to prevent my certificates being declared invalid because CRL requests<br>
> fail?<br>
<br>
yes.<br>
<br>
> Thirdly, I would like to understand the difference between the 'digest'<br>
> and the 'cipher' and what roles they perform in the communication<br>
> process, especially in relation to the actual signing algorithm. As an<br>
> aside: I've noticed that using any of the `sha3-*` digests somehow<br>
> prevents Windows 10 from verifying my certificates.<br>
<br>
cipher would not be used in a CA.<br>
I would guess Windows10 does not support SHA3?<br>
<br>
> Onto more practical concerns, I am thoroughly confused by how many<br>
> OpenSSL tools seemingly perform the same tasks. For example, one can<br>
<br>
Yes, because the "openssl" tool is not really intended to be for production.<br>
It exists mostly to allow the libraries to be configured and tested.<br>
So, it evolved based upon the need of the day, not any master design.<br>
<br>
I've argued for splitting much of the higher-layer functions that it does<br>
into a different git repo, as the tool is too intimate with the libraries,<br>
and the continue to be things you can't (easily) do programatically, but the<br>
tools do.<br>
<br>
> Finally, if anyone happens to be in possession of an exhaustive<br>
> configuration file that includes *all* possible sections and fields<br>
> supported by OpenSSL, I would very much appreciate a copy!<br>
<br>
Not me.<br>
A Xmas-Lights configuration would be interested to look at, but likely more<br>
confusing than useful.<br>
<br>
</blockquote></div>