CA/Server configuration

[Lynch, Pat]

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 <openssl-users-bounces at openssl.org> On Behalf Of Cyprus Socialite
Sent: Thursday, September 29, 2022 11:07 AM
To: openssl-users at 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 concerns, I am thoroughly confused by how many OpenSSL tools seemingly perform the same tasks. For example, one can generate a certificate using any one of `req`, `ca`, and `x509 -req`. I understand that some of these have additional functionality, such as generating key, CSR, and certificate all at once, so I would like to know what the go-to lowest-level, DOTADIW tools are for these purposes. At the moment, I am using `genpkey` for, well, private key generation, and `req -new` for the CSR.

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!

I hope I've managed to present my questions clearly enough, but would be happy to provide clarifications if needed.


Thanks


---------

“The nice thing about standards is that there are so many to choose from”
— Andrew S. Tanenbaum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220929/884612b9/attachment-0001.htm>