#144 getcert request -a has no effect
Opened 4 years ago by cheimes. Modified 4 years ago

The -a option is documented as -a NSS database in which to store the CA's certificates. It's suppose to add root CA and intermediate CA certificates for a requested certificate. But it doesn't work for me:

# mkdir /tmp/nssdb
# echo Password > /tmp/nssdb/passwd
# certutil -d /tmp/nssdb -f /tmp/nssdb/passwd -N
# ipa-getcert request -w -v  -d /tmp/nssdb -n test -p /tmp/nssdb/passwd -a /tmp/nssdb
New signing request "20200217143245" added.
State NEWLY_ADDED_READING_KEYINFO, stuck: no.
State NEWLY_ADDED_READING_CERT, stuck: no.
State GENERATING_KEY_PAIR, stuck: no.
State READING_KEYINFO, stuck: no.
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State READING_CERT, stuck: no.
State MONITORING, stuck: no.
# certutil -d /tmp/nssdb/ -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

test                                                         u,u,u
# ipa-getcert list -i 20200217143245 
Number of certificates and requests being tracked: 14.
Request ID '20200217143245':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/tmp/nssdb',nickname='test',token='NSS Certificate DB',pinfile='/tmp/nssdb/passwd'
        certificate: type=NSSDB,location='/tmp/nssdb',nickname='test',token='NSS Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=IPA.EXAMPLE
        subject: CN=host-10-0-136-183.ipa.example,O=IPA.EXAMPLE
        expires: 2022-02-17 09:32:47 EST
        dns: host-10-0-136-183.ipa.example
        principal name: host/host-10-0-136-183.ipa.example@IPA.EXAMPLE
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command: 
        post-save command: 
        track: yes
        auto-renew: yes

As you can see the NSSDB doesn't contain any root certificates. The information is stored in the request tracking file:

# grep root /var/lib/certmonger/requests/20200217143245 
root_cert_dbs=/tmp/nssdb

Memo to me: internally the path is handled by property CM_DBUS_PROP_ROOT_CERT_NSSDBS. It took me a while to figure out the internal name of the argument.


The -F option isn't working for me either.

I forgot to mention the version numbers:

  • certmonger-0.79.9-1.fc31
  • freeipa-server-4.8.4-2.fc31

I'm not able to reproduce, maybe the DB location (SELinux). I used /etc/pki/nssdb and no password:

# rpm -q certmonger
certmonger-0.79.9-1.fc30.2.x86_64
# ipa-getcert request  -d /etc/pki/nssdb -n test -a /etc/pki/nssdb -K test/`hostname`
# certutil -L -d /etc/pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

test                                                         u,u,u
EXAMPLE.TEST IPA CA                                          CT,C,C

And for the -F:

# ipa-getcert request  -f /etc/pki/tls/certs/test.pem -k /etc/pki/tls/private/test.key -K test/`hostname` -F /etc/pki/tls/test.CA
# ll /etc/pki/tls/test.CA 
-rw-------. 1 root root 1639 Feb 17 14:51 /etc/pki/tls/test.CA

It doesn't work for me on F31:

# rpm -qa certmonger
certmonger-0.79.9-1.fc31.x86_64
# ipa-getcert request  -d /etc/pki/nssdb -n test -a /etc/pki/nssdb -K test/`hostname`
New signing request "20200218140520" added.
# sleep 30
# certutil -L -d /etc/pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

test                                                         u,u,u
# ipa-getcert request  -f /etc/pki/tls/certs/test.pem -k /etc/pki/tls/private/test.key -K test/`hostname` -F /etc/pki/tls/test.CA
New signing request "20200218140846" added.
# ls /etc/pki/tls/test.CA
ls: cannot access '/etc/pki/tls/test.CA': No such file or directory

I've reproduced it with the -F flag on F31. Interestingly when I restarted certmonger it created the CA file. It may be a scheduling issue in certmonger, will investigate.

Restarting certmonger creates the CA file from -F. At that point in time the cert request is about 45 minutes old.

# systemctl restart certmonger
# ls -la /etc/pki/tls/test.CA 
-rw-------. 1 root root 1635 Feb 18 10:31 /etc/pki/tls/test.CA
# date
Tue Feb 18 10:31:54 EST 2020

A restart does not add the CA to the NSSDB. I copied your commands verbatim.

Duplicated that behavior too.

Next I started with a fresh install, restarted certmonger, and the request was successful, NSDB updated. A lame workaround in any case.

Login to comment on this ticket.

Metadata