X509V3_EXT_nconf_int:error in extension:crypto/x509/v3_conf.c:48:section=req_ext, name=extendedKeyUsage, value=

[Robert Moskowitz]

Ah, not wrong docs.  Wrong reading:

-reqexts section

     These options specify alternative sections to include certificate 
extensions (if -x509 is in use) or certificate request extensions. This 
allows several different sections to be used in the same configuration 
file to specify requests for a variety of purposes.

Thus is included in a csr.  I see that now there is a -addext option and 
this might well be the way to go on the command line rather than in the 
config file.  Testing now.

On 7/5/23 12:39, Robert Moskowitz wrote:
> Oow, the docs are wrong!
>
> -regexts DOES work without the -x509 option.
>
> Or at least my reading of the docs at:
>
> https://www.openssl.org/docs/man3.1/man1/openssl-req.html
>
>
>
> On 7/5/23 12:34, Robert Moskowitz wrote:
>>
>>
>> On 7/5/23 12:15, Viktor Dukhovni wrote:
>>> On Wed, Jul 05, 2023 at 11:51:42AM -0400, Robert Moskowitz wrote:
>>>
>>>> I have:
>>>>
>>>> [ req_ext ]
>>>> basicConstraints = $ENV::basicConstraints
>>>> keyUsage = $ENV::certkeyusage
>>>> extendedKeyUsage = $ENV::certextkeyusage
>>>> subjectAltName = $ENV::subjectAltName
>>>>
>>>> And sometimes I want these variables to be empty.  That is not to be
>>>> included in the csr.
>>>>
>>>> I thought that I had this working, but guess not.
>>>>
>>>> How can I have is so that some csr are created with all of these and
>>>> others only some?
>>> Use separate config files.  I always construct config files "on the 
>>> fly":
>>>
>>>      $ openssl ... -config <(
>>>          cat common-bits.cnf
>>>          printf " ... custom bits %s ... \n" "$arg1" ...
>>>          printf " ... more custom bits %s ... \n" "$arg1" ...
>>>          ...
>>>          )
>>
>> Uh, yeah.  I was trying to keep this simple and more usable and 
>> understandable.
>>
>> I looked at the -regexts option to have various such, but that, 
>> according to the docs, is only available with the -x509 option that 
>> you don't use for making a csr.
>>
>> Maybe use -extensions?  and load all the req_ext in specific 
>> extensions rather than default to req section?
>>
>>
>>> And don't use the "$ENV" feature.  For advanced examples of that
>>> pattern see:
>>
>> And what is wrong/bad with $ENV?  Without it I would need a separate 
>> config file for pretty much all of the openssl commands I am using. I 
>> was pointed to it some years back.
>>
>> But thanks for these examples.
>>
>>>
>>> https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh
>>>
>>> It depends on your shell (e.g. bash) supporting inline <( ... ) files
>>> (under the covers /dev/fd/<pipe-fd-number>).  Works for any file that
>>> is read sequentially from the start without seeking (pipes don't 
>>> lseek).
>>>
>>> You can of course also curate multiple config templates that use 
>>> various
>>> subsets of the desired parameters, or a single script can look at which
>>> environment variables are set and generate the correspondig config on
>>> the fly as above, or in tempfile:
>>>
>>>      cnf=$(mktemp -t cnf.XXXXXX)
>>>      trap 'rc=$?; '"rm -f ${cnf}; "'exit $rc' EXIT HUP INT TERM
>>>
>>>      ... generate custom config in "$cnf" ...
>>>      openssl -config "$cnf" ....
>>>
>>
>