Error loading extension section server

Error Loading extension ‘copy_extensions’ in Openssl

While running the following command on Ubuntu 19.10, with OpenSSl 1.1.1c 28 May 2019:

I receive the following output:

Error Loading extension section v3_ca

140710502360256:error:22097082:X509 V3 routines:do_ext_nconf:unknown extension name. /crypto/x509v3/v3_conf.c:78:

140710502360256:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension. /crypto/x509v3/v3_conf.c:47:name=copy_extensions, value=copy

With the following config file:

The error eludes me, and to give some background, my attempt to is use copy_extensions so that when I pass in a subjectAltName via -addext (or via any means) to the CSR, the subjectAltName will pass into the signed cert when executing the following (the following are openssl commands for the Intermediate Cert to sign and create a client or server based cert, and it all functions fine, except for what I just stated):

1 Answer 1

You’re not far off — copy_extensions is not an extension, it needs to be in the CA_Default section to instruct the CA to copy extensions from the CSR to the signed certificate.

Example below, see the last line:

Some useful resources on openssl can be found at the links below:

(These links all point to www.phildev.net — I am not associated with this site in anyway, but have found the content informative and easy to understand.)

To quote one part:

The «ca» section defines the way the CA acts when using the ca command to sign certificates.

In your case, the default CA’s section is CA_default (your actual «ca» section points to this).

Your best resource for specific commands is the Openssl docs themselves. On the linked page, you’ll find the explanation for how to use -addext. As far as I can tell your usage is accurate, but it is possible the issue is in the variable. There’s also a good answer on this here: Provide subjectAltName to openssl directly on the command line.

If your extensions are consistent, you can simply add them into the config file under whichever section $ refers to. You can of course specify multiple sections in the config file and select the correct section in each command using the -extensions flag.

Источник

openssl: generate certificate request with non-DNS subject alternative names

To create a certificate request containing subject alternative names (SANs) for a host, with openssl, I can use a config file like this (snipped):

If I need to provide a distinguished name or a user principal name, how should I configure the alt_names section for a user certificate request?
For example, I tried

But I got this error:

3 Answers 3

You can specify pretty much anything that your CA allows.

The relevant RFC is RFC5280. It says in section 4.2.1.6. «Subject Alternative Name»

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4. Note that where such names are represented in the subject field implementations are not required to convert them into DNS names.

You should read the rest of that section, and then check with your CA what they support. It’s worth noting that your CA must verify that all subject alternative names are correct.

To use an email address, the RFC says in section 4.1.2.6

Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (Section 4.2.1.6) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted.

So instead of UPI, you should use rfc822Name.

Источник

Provide subjectAltName to openssl directly on the command line

Is it possible to provide a subjectAltName-Extension to the openssl req module directly on the command line?

I know it’s possible via a openssl.cnf file, but that’s not really elegant for batch-creation of CSRs.

18 Answers 18

As of OpenSSL 1.1.1, providing subjectAltName directly on command line becomes much easier, with the introduction of the -addext flag to openssl req (via this commit).

The commit adds an example to the openssl req man page:

This has been merged into the master branch of the openssl command on Github, and as of April 18 2018 can be installed via a git pull + compile (or via Homebrew if on OS X: brew install —devel openssl@1.1 ).

Note that if you have set the config attribute «req_extensions» at section «[req]» in openssl.cfg, it will ignore the command-line parameter

Based on link from DarkLighting, here’s the command I came up with using nested subshells.

This is my solution to finally generate a working self signed cert, based on the answers above(The accepted answer don’t work for me):

openssl x509 -in server.crt -text -noout :

Repro step for «The accepted answer don’t work for me» (On OSX 10.12.4, with system openssl):

My solution was to pass subjectAltName via an environment variable.

First have this added to openssl.conf :

Then set the environment variable before invoking openssl:

Note: the -extensions san_env parameter needs to be present when signing the CSR as well as when generating it. Therefore, for CA-signed CSRs add -extensions san_env to the openssl ca command as well.

As of 2022, with OpenSSL ≥ 1.1.1, the following command demonstrates how to generate a self-signed certificate with SAN for example.com and example.net :

Here we are using the -addext option.

If you are stuck to OpenSSL ≤ 1.1.0, e.g. on Debian ≤ 9 or CentOS ≤ 7, you can apply instead a tiny hack via -extensions and -config . The following command is portable in the sense that we don’t have to mess around with (or even know about) the location of the openssl.cnf file:

The trick here is to include a minimal [req] section that is good enough for OpenSSL to get along without its main openssl.cnf file.

Either way, don’t forget to verify the contents of the generated certificate:

So I had a heck of a time getting this working right, and putting at all in Ansible. As Ansible’s command module doesn’t allow file-redirects ( ), I had to use a small .cnf file as a template, but it’s all working now. Here’s what I did to make it work:

The san.cnf template (generated for each CSR/CRT pair):

Some Variables

These Ansible variables used in the following commands, but you can substitute as needed in your scripts:

key ssl_certs_local_caserial_path: The CA’s serial numbering file ssl_certs_local_cert_path: The final generated certificate file.

The CSR Generation Command

Self-Signing the CSR to create the Certificate

To Verify the Result

That should include a section that appears as follows:

The 2nd post in this link says that it not possible to do that only from command line, but the 4th post in the same link provides a workaround using bash’s ability of referencing data as if it was in a file.

Taking a further look into it, someone mentioned the reqexts parameter used to make additions to certificate request. This blog uses bash’s env as an approach to this.

But i’m just trying to help. Haven’t tested any of this myself.

Tested for RHEL7 (creating a self-signed certificate with a SAN)

I wanted a one line command to create a CSR — worked perfectly with no conf files, but didn’t generate a SubjAltName entry. This version is what I was using Using read -p to request FQDN I wanted this to work with a SAN entry as well — so here’s a working solution.

There is a dependency on the version of openssl, needs to be at least 1.1.1. because you need -addext.

No messing with conf files this way.

My solution to this problem was to create and reference a temporary cnf file by appending my command-line-collected subjectAltName information.

I needed to do this for creating self-signed certs for local testing, but also wanted to be able to pass multiple parameters for extensions, not just SAN. I discovered that doing multiple -extfile commands, just seemed to overwrite each other, and only the last -extfile value ended up in cert.

The solution was just to add more variables to the printf:

That works fine, but our workflow was already generated certs by storing the command in a package.json file, and then running npm run newcert . Attempting to add n to the printf just broke the command. The solution for this was to switch to using a lot of echos, along with explicitly defining an extension name.

• Note: For running these as an npm script, you’ll have to escape the double quotes, and line continuations can’t be used.

Running openssl x509 -noout -text -in cert.pem shows it worked:

The question has been answered, but I still struggled with getting this into an elegant and useful form to automate CSR generation. The one liner is nice so I incorporated it into a routine that allows the subject alternative names as command arguments rather than values in a file also the flexibility to SAN or not to SAN. Try it with one argument then with many.

This has been answered, but if anyone’s still looking for a no-prompt, cli-only method to create a self-signed root cert (without CAs or CSRs) and don’t mind using Java keytool , here’s an alternative:

Generate a PKCS12 keystore with keytool

Export Certificate and Key with openssl

As an addition to the answer by @Excalibur (btw. thank you for your work!)

I find this form a bit more suited for Ansible. It sidesteps the problems of the official module openssl_csr that is somewhat difficult to work with due to library dependency and version problems.

The following is an adaptation of a part of the script generation by @Excalibur. You don’t need to create a file. This particular playbook outputs the certificate to stdin which you can show with ( ansible-playbook -vvvv

) or dump to a variable and output using the debug module.

The domain.key needs to be in the same directory as the playbook.

Simple answer is: you need two separate sections for requesting and signing certificates.

In signing section, REMOVE subjectAltName specification altogether.

Then it’ll pass from the request.

Create a copy of the default openssl.cnf file and add the line below in the [req] section:

Then, add the content below under the req_extensions section:

Once the custom config file is created, explicitly specify this config file while creating a CSR:

Link to my working modified openssl config file:

Shout out to Thiyagarajen’s solution

[Background] Was trying to generate CSR with adding in SAN

After few experiments, here’s what I did after reading all useful solutions here and various sources.

If the OpenSSL configuration file is defined well, then we could use -config myopenssl.cnf without the need of -reqexts param.

First, you would need to create an OpenSSL configuration file .cnf .

For example, nano myopenssl.cnf

Below is a template OpenSSL configuration file

Once you have configured well your .cnf , let’s proceed to generate the CSR

// Generate Certificate Signing Request(CSR) using existing key without creating a new key

// Generate CSR with «new» RSA 2048 key

Based on my current understanding, I will try my best to explain the above configuration. Please correct me if I’m wrong

Under [req] section,

1. distinguished_name = req_distinguished_name
   First, we need to understand what distinguished name is?
   Distinguished Name (DN) is a set of values entered during enrollment and the creation of a Certificate Signing Request (CSR) such as:
   • C= Country (2 character country code such as US)
   • ST = State (must be spelled out completely such as New York or California)
   • L = Locality/City
   • O = Organization (legal company name)
   • OU = Organizational Unit (division or department of company but this is an optional field)
   • CN = Common Name (the fully qualified domain name such as www.digicert.com)

So, distinguished_name = req_distinguished_name will point the OpenSSL to find the set of values under [req_distinguished_name] section and there’s no need for us to use -subj param.

req_extensions = v3_req
Will point to [v3_req] section, whereby you could define any of the extension attributes you wish to add, in our case is just the subjectAltName . So, we could take out the keyUsage and extendedKeyUsage attributes. So, there’s no need to use -reqexts anymore to point to the SAN section when you define «req_extensions = v3_req» and at which you subjectAltName resides in this [v3_req] section!(When generating a CSR, like this, ‘req’ could use the commandline option -reqexts or straight from the defined configuration file entry req_extensions.)

prompt = no
Will not prompt you to enter the Distinguised name like usual, instead it will used the one configured inside this cnf file [req_distinguished_name] section.

Under [req_distinguished_name]

From the OpenSSL commandline return message,

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.

However, from my testing, it seem like could not leave country (C) with ‘.’, else will hit error like: 140027926083488:error:0D07A098:asn1 encoding routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=2

Below is a sample snippet of leaving blank for the distinguished name.

Under [v3_req]

We could either define subjectAltName in just one line like the upvoted solutions given in this thread or we could point subjectAltName to a «section» we created as shown in the template OpenSSL configuration file shown above.

Either
subjectAltName=DNS:example.com,DNS:www.example.com,IP:10.0.0.1,IP:10.0.0.2

Or

Under [alt_names]

IP address must be in range of 0.0.0.0 — 255.255.255.255

Источник

While running the following command on Ubuntu 19.10, with OpenSSl 1.1.1c 28 May 2019:

openssl req -config ${CNF_FILE} -key ${PRIVATE_FILE} -new -x509 -days 10950 -sha384 -extensions v3_ca -out ${CERT_FILE}

I receive the following output:

Error Loading extension section v3_ca

140710502360256:error:22097082:X509 V3 routines:do_ext_nconf:unknown extension name:../crypto/x509v3/v3_conf.c:78:

140710502360256:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=copy_extensions, value=copy

With the following config file:

[ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = /home/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca_ecc.key.pem
certificate       = $dir/certs/ca_ecc.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = US
stateOrProvinceName_default     = My State
localityName_default            = My City
0.organizationName_default      = My Company
organizationalUnitName_default  = My Office
emailAddress_default            = certificates@certificates.com

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
copy_extensions = copy
preserve = yes

The error eludes me, and to give some background, my attempt to is use copy_extensions so that when I pass in a subjectAltName via -addext (or via any means) to the CSR, the subjectAltName will pass into the signed cert when executing the following (the following are openssl commands for the Intermediate Cert to sign and create a client or server based cert, and it all functions fine, except for what I just stated):

openssl ${algo_GEN} -out $PRIVATE_FILE

openssl req -config $CNF_FILE -key $PRIVATE_FILE -new -addext "subjectAltName = ${SAN_LIST}" -sha384 -out $CSR_FILE << EOF





${CERT_ID}

EOF

openssl ca -batch -config $CNF_FILE -extensions ${EXTENSION} -days 375 -notext -md sha384 -in 

Trying to create the root certificate using:

openssl req -config openssl.cnf 
    -key private/ca.key.pem 
    -new -x509 -days 7300 -sha256 -extensions v3_ca 
    -out certs/ca.cert.pem

I am getting the following error.

Error Loading extension section v3_ca

I have looked over the config to make sure I didn’t fat finger anything but the section v3_ca is there and has all the parameters it needs. I’ve never set this up before so I’m not familiar with the pitfalls. Could someone point me in the right direction as to what I’m doing wrong? I have pasted my full config file here so you can look it over if you are so inclined.

[ ca ]
# 'man ca'
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir                     = /root/ca
certs                   = $dir/certs
crl_dir                 = $dir/crl
new_certs_dir           = $dir/newcerts
database                = $dir/index.txt
serial                  = $dir/serial
RANDFILEq               = $dir/private/.rand

# The root key and root certificate.
private_key             = $dir/crlnumber
crl                     = $dir/crl/ca.crl.pem
crl_entensions          = crl_ext
default_crl_days        = 30

# SHA-1 is depricated, use SHA-2
default_md              = sha256

name_opt                = ca_default
cert_opt                = ca_default
default_days            = 375
preserve                = no
policy                  = policy_strict

[ policy_strict ]
# The root ca should only sign intermediate certificates that match.
# See the POLICY FORMAT section of 'man ca'.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the 'man ca'.
countryName             = optional
stateOrProvinceName     = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
# Options for the 'req' tool.
# See 'man req'.
default_bits            = 4096
distinguished_name      = req_distinguished_name
string_mask             = utf8only
default_md              = sha256
x509_extensions         = v3_ca

[ req_distingushed_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
country_Name            = Country Name (2 letter code)
stateOrProvinceName     = State or Province Name
lacalityName            = Locality Name
0.organizationName      = Organization Name
organizationalUnitName  = Organizational Unit Name
commonName              = Common Name
emailAddress            = Email Address

# Here are some default values
countryName_default             = US
stateOrProvinceName_default     = Nebraska
localityName_default            = Minden
0.organizationName_default      = RoyalEng
#organizationalUnitName_default =
#emailAddress_default           =

[v3_ca]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning