4

We use a CA that expects a challengePassword, so I set up a openssl.cnf like this:

oid_section            = OIDs

[ req ]
distinguished_name     = req_distinguished_name
attributes             = req_attributes
req_extensions         = v3_req

[ OIDs ]
RequestProfile         = 1.3.6.1.4.1.311.20.2

[ req_distinguished_name ]
commonName             = Common Name
organizationalUnitName = Organizational Unit Name
organizationName       = Organization Name
localityName           = Locality Name
stateOrProvinceName    = State or Province Name
countryName            = Country

[ v3_req ]
basicConstraints       = CA:FALSE
keyUsage               = digitalSignature, keyEncipherment
subjectKeyIdentifier   = hash
subjectAltName         = @alt_names
RequestProfile         = ASN1:BMP:tlsserver

[ alt_names ]
IP                     = 192.168.0.1
DNS                    = test.unit.org.ch

[ req_attributes ]
challengePassword      = ChallengePassword

I created a certificate request with

openssl req \
   -new -keyout test.key -out test.csr \
   -subj /C=ch/ST=BE/L=Berne/O=org/OU=unit/CN=test.unit.org.ch \
   -newkey rsa:2048 -nodes -config openssl.cnf

As far as I can tell, the test.csr looks generally fine, except the Attributes list is empty. I was expecting to see the challenge password there:

[simon@centos Projects]$ openssl req -noout -text -in test.csr 
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=ch, ST=BE, L=Berne, O=org, OU=unit, CN=test.unit.org.ch
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ce:b2:52:74:40:5e:c4:73:13:2a:08:ec:94:ea:
                    [...]
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 Subject Key Identifier: 
                37:1E:95:70:3B:27:BA:8F:09:77:E4:42:DD:FD:A8:DD:29:01:F0:51
            X509v3 Subject Alternative Name: 
                IP Address:192.168.0.1, DNS:test.unit.org.ch
            1.3.6.1.4.1.311.20.2: 
                ...t.l.s.s.e.r.v.e.r
    Signature Algorithm: sha256WithRSAEncryption
         0b:5e:96:a2:83:b0:d5:08:1f:d0:34:e3:d4:c4:37:53:f2:28:
         [...]

This is with OpenSSL version 1.0.2k (CentOS 7.5), but also happens on RHEL 7.3 with version 1.0.1e.

I am probably misunderstanding something very basic - could someone please give me a hint?

1 Answer 1

2

The man page doesn't tell you, but if you look at the code the logic for the distinguished_name (subject) section and the attributes section are actually commingled. When you use prompt=no in the config file it affects both of them, and when you use -subj on the command line it uses a different code path that skips, and thus effectively disables, attributes.

Barring a fairly major reorganization of the code, if you want attributes you can't use -subj. You can use the default where you are prompted for both DN and attributes values, or set prompt=no with both values in the config file. If you don't want to actually edit the config file (or versions of it), remember in some Unix shells (including CentOS) you can use process substitution like:

 openssl req -new -config <(cat fixedpart; printf '%s\n' '[req_DN]' 'commonName=test.invalid' '[req_attributes]' 'challengePassword=letmein') ...
1
  • I wanted to pass the (node-specific) subject as a command line option and have the config file just define the common attributes. But since all of that will be done by an ansible playbook, creating node-specific configuration files is no problem at all. That works. Many thanks!
    – simonz
    May 17, 2018 at 12:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .