RE: CA/Server configuration
> From: openssl-users On Behalf Of Dmitrii > Odintcov > Sent: Sunday, 2 October, 2022 21:15 > > This is where the confusion begins: if ‘bar’, the certificate requestor, > itself > wants to be a CA (basicConstraints = CA:true), I assume here you mean bar is going to be a subordinate CA for foo, or bar is a subordinate that's being cross-signed by foo. Otherwise foo issuing a CA certificate for bar doesn't make sense. Note that bar can't be a root, since it'll be signed by some entity other than itself. (A root is a self-signed CA certificate, by definition.) > then its bar.conf must answerboth sets of questions at the same time! Why? Creating a CSR and generating the certificate for it are separate operations. bar's configuration is used in creating the CSR. foo's is used in generating the certificate. > 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? Oh, I see, you're talking about generating bar's CSR versus signing certificates using bar. The answer is: you have two configurations, one for generating bar's CSR and the other for signing certificates using bar. Those are separate operations (obviously, since bar can't sign anything until it has its certificate), so they're not required to use the same configuration. Configuration files are tied to *operations*, not to *entities*. You use the configuration file appropriate for the operation, where an operation is something like "requesting a CSR for a subordinate CA" or "signing a certificate for a subordinate CA" or "signing a certificate for a non-CA entity". -- Michael Wojcik
Re: CA/Server configuration
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 wrote: > > Cyprus Socialite 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
Re: CA/Server configuration
Cyprus Socialite 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. signature.asc Description: PGP signature
RE: CA/Server configuration
Hello Cyprus, I’m not exactly what you’d call an expert on openssl, but I do use it frequently. There is a very good openssl wrapper project called EasyRSA that I highly recommend. We put together a very simple Certificate Authority for application testing using this package and it made things much easier. You can find it here: https://github.com/OpenVPN/easy-rsa Now to address your questions… First, -config allows you to specify a configuration file to use for the operation – from the OpenSsl documentation: (https://www.openssl.org/docs/man1.1.1/man1/openssl.html) Many commands use an external configuration file for some or all of their arguments and have a -config option to specify that file. The -extensions option allows you to provide certain configuration options (called extensions) on the command line instead of in a configuration file. These extensions are typically within the realm of X509 (certificates, CSRs, CRLs and the like). For example there is an Extended Key Usage extension - see https://www.openssl.org/docs/man1.1.1/man5/x509v3_config.html Second, depending on the operation and the specific configuration field, the lack of a value might result in a default value being used or it might cause the absence of the resulting field in the result of the operation. For example, if you don’t specify the digest when running openssl req it defaults to sha256 (but that also depends on the specified public key algorithm). In contrast, if you don’t specify the OCSP responder URI when signing a CSR there will not be an OCSP responder URI in the resulting signed certificate. Is it possible to create an unusable certificate with openssl? Probably. But, in general, it’s the application that is conducting the validation of your certificates that determines whether the certificate is rejected. An application might accept the certificate without any revocation checking extensions (CRL or OCSP) or prompt whether to trust it. I guess Windows 10 doesn’t support sha-3* digests and so rejects the certificate. Other operating systems and/or applications might very well accept the same certificate. Third, you’ll need to throw a study on the SSL/TLS protocols to understand how ciphers and digests are used in the communication process (I’m assuming that’s what you mean by communication). Yes, there are multiple ways to perform some operations – welcome to openssl. The differences typically allow for an operation “centric” approach meaning each operation has specific defaults that may differ from other operations or one operation might provide multiple outputs whereas another only provides one as you observed. My advice here is to choose the operation that makes the most sense with respect to the desired end result or the operation that ends up being easier for you to code against. With respect to a configuration reference, here is my go-to: https://www.phildev.net/ssl/opensslconf.html I don’t know whether it’s 100% complete or not but it has served me well. Cheers! -Pat From: openssl-users On Behalf Of Cyprus Socialite Sent: Thursday, September 29, 2022 11:07 AM To: openssl-users@openssl.org Subject: CA/Server configuration CAUTION: Email originated externally. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello 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 configuration of the Intermediate CA due to its role as both a requester and a provider of certificates. The first and perhaps most fundamental thing unclear to me is what the configuration and extensions (provided via -config and -extensions arguments) actually configure and extend. For instance, does `default_ca` specify the parameters of the CA I'm operating, or the CA I'm requesting a certificate from? Does the `[req]` section configure the requests I create or the way I process others' requests (and so the certificates I output)? To further the confusion, the `copy_extensions` setting seems to imply that the extensions exist on both the CA and the requester side! 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) 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? 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. Onto more practical
