certmonger-session

There is more to the certmonger story. A lot more. After my last attempt I tried to use certmonger:

  • as a user-launched process
  • to get a user certificate
  • direct from the dogtag instance behind FreeIPA

I was not 100% successful, but the attempt did have some positive results.


The whole thing started with an ipa-server-install.

To be able to talk direct to Dogtag, though, I opened a few additional ports on the Firewall

Added these lines in /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT
service iptables restart

As part of the IPA install, it records a couple of PKCS12 files with enough information to talk to your Dogtag instance. These are in /root, but I copied them to the /home/fedora directory to make them accessible via scp to my desktop.

scp fedora@hostname:ca-agent.p12 .

I ran Firefox and imported the certificates
From the menu select
edit->preferences
That will pop up the preferences dialog, and select the Advanced tab and the Certificates subtab.
advancedClick view certificates and then “Your Certificates” on that panel, and finally click the Import Button.

cert-manager

Yeah, that is pretty hostile.

I had to add the hostname and ip address for the ipa server int /etc/hosts for my laptop in order to get an https connect to dogtag, but I got it with: https://hostname:8443/ Note that it uses the certificates imported from ca-agent.p12 to connect.

First I made things work as root: I created a new CA configuration for the certmonger system daemon
[root@ipa cas]# cat /var/lib/certmonger/cas/ipa-ca

id=dogtag-ipa
ca_is_default=0
ca_type=EXTERNAL
ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit -i /etc/ipa/ca.crt -E http://ipa.openstack.freeipa.org:8080/ca/ee/ca -A https://$HOSTNAME:8443/ca/agent/ca/

And I was able to request a certificate with:

sudo getcert request -c dogtag-ipa -f /etc/pki/testcert -k /etc/pki/testkey -N cn=someothername

That submitted the request. In an ordinary dogtag setup, certificate are not automatically approved. I had to approve it using the web UI on
Approval on: https://$HOSTNAME:8443/ca/agent/ca/

Once it is approved, you can either wait 8 hours for the next query or run a resubmit to get the status and fetch the cert:

sudo getcert resubmit -i 20140226001609

And if you forgot the id you can get it with

sudo getcert list -s

Cert is fetched and placed into /etc/pki/testcert. The key should already have been made in /etc/pki/testkey

(Actually, certmonger crashed, due to a bug that had already been fixed but not yet landed in the yum repo. I reinstalled with an internal build, but you can find yours here: When we restarted the certmonger daemon, it picked right up and succeeded.)

Now to try and get a user cert using the user-runnable version of certmonger. This is called certmonger-session, but you don’t run it directly. It is a dbus driven service. This was done on the ipa server machine, which has no X server on it. If there was, there would be a dbus daemon running, but since there is not:

export DBUS_SESSION_BUS_ADDRESS=`dbus-daemon --session --fork --print-address`

It looks like this:

unix:abstract=/tmp/dbus-ym4pEDwUcj,guid=e7a9adfd8ae299213a39f57a530d3891

To run certmonger:

getcert list-cas -s

The -s option makes it a session request as opposed to talking to the systemd managed server. This creates
~/.config/certmonger but no cas subfolders under there yet. They get written upon certmonger-session exit:

killall certmonger-session

Will dump them into .config/certmonger/cas/. They are named by time stamp:

ls .config/certmonger/cas/
20140226004653  20140226004653-1  20140226004653-2  20140226004653-3

now create .config/certmonger/cas/ipa-dogtag (while daemon is not running, as killing daemon will overwrite the config…) with these contents (using your own hostname):

id=ipa-dogtag
ca_is_default=0
ca_type=EXTERNAL
ca_external_helper=/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit -i /etc/ipa/ca.crt -E http://ipa.openstack.freeipa.org:8080/ca/ee/ca -A https://ipa.openstack.freeipa.org:8443/ca/agent/ca/ -T caUserCert

And checkout out that your new CA entry is available with: getcert list-cas -s

CA 'SelfSign':
	is-default: no
	ca-type: INTERNAL:SELF
	next-serial-number: 01
CA 'IPA':
	is-default: no
	ca-type: EXTERNAL
	helper-location: /usr/libexec/certmonger/ipa-submit
CA 'certmaster':
	is-default: no
	ca-type: EXTERNAL
	helper-location: /usr/libexec/certmonger/certmaster-submit
CA 'dogtag-ipa-renew-agent':
	is-default: no
	ca-type: EXTERNAL
	helper-location: /usr/libexec/certmonger/dogtag-ipa-renew-agent-submit
CA 'ipa-dogtag':
	is-default: no
	ca-type: EXTERNAL
	helper-location: /usr/libexec/certmonger/dogtag-ipa-renew-agent-submit -i /etc/ipa/ca.crt -E http://ipa.openstack.freeipa.org:8080/ca/ee/ca -A https://ipa.openstack.freeipa.org:8443/ca/agent/ca/ -T caUserCert

Need a place to hold the certs:

mkdir ~/.pki

Since you are running as a user, unconfined, you don’t need to worry about SELinux. If you were somehow to run this non-interactivly, you would need to run

sudo chcon -t cert_t .pki/

Or do something more permanent.

To request a user certificate:

getcert request -c ipa-dogtag -s -f ~/.pki/ayoung.cert.pem -k ~/.pki/ayoung.key.pem -N "uid=ayoung,cn=users,cn=accounts,dc=openstack,dc=freeipa,dc=org"

and to see the request


$ getcert list -s
Number of certificates and requests being tracked: 1.
Request ID '20140226005825':
status: CA_REJECTED
ca-error: Server at "http://$HOSTNAME:8080/ca/ee/ca/profileSubmit" replied: Subject Name Not Found

WHAT! Yeah, doesn’t work yet. Kill the request for now:

getcert stop-tracking -s -i 20140226005825

So it looks like the caUserCert profile does not accept a PKCS11 request, as it is set up to come from the Web Browser, and those use Certificate Request Message Format (CRMF). I’ve been able to hack around it (I think) but there is still more to learn here.

5 thoughts on “certmonger-session

  1. Hi, i’m having a curious problem – request get entered into dogtag, but certmonger thinks there is a problem

    Request ID ‘20150210125814’:
    status: NEED_GUIDANCE
    stuck: yes
    key pair storage: type=FILE,location=’/etc/pki/testkey’
    certificate: type=FILE,location=’/etc/pki/testcert’
    CA: dogtag-ipa
    issuer:
    subject:
    expires: unknown
    pre-save command:
    post-save command:
    track: yes
    auto-renew: yes
    [root@fedora pki]# vim /var/lib/certmonger/cas/ipa-ca
    (reverse-i-search)`0′: getcert refresh -i 2015021^C25814

    [root@fedora pki]# systemctl status -l certmonger
    (….)
    lut 10 13:57:04 fedora.box.net certmonger[7845]: Request for certificate to be stored in file “/etc/pki/testcert” rejected by CA.

    The command issuing the request actually doesn’t give any errors. Accepting the request doesn’t make certmonger notice it.

    Is that some kind of known issue?

  2. Got the following info from Nalin D:

    NEED_GUIDANCE usually only happens when the daemon
    can’t understand the exit status returned by the helper, and if it’s
    already logged that the server’s rejected the request (which is
    communicated by the helper’s exit status), that’s not the code path it’s
    on. Likewise, the only other path that leads to that state involves not
    having a location set for storing the private key.

    > Request ID ‘20150210125814’:
    > status: NEED_GUIDANCE
    > stuck: yes
    > key pair storage: type=FILE,location=’/etc/pki/testkey’
    > certificate: type=FILE,location=’/etc/pki/testcert’
    > CA: dogtag-ipa
    > issuer:
    > subject:
    > expires: unknown
    > pre-save command:
    > post-save command:
    > track: yes
    > auto-renew: yes
    > [root@fedora pki]# vim /var/lib/certmonger/cas/ipa-ca
    > (reverse-i-search)`0′: getcert refresh -i 2015021^C25814
    >
    >
    > [root@fedora pki]# systemctl status -l certmonger
    > (….)
    > lut 10 13:57:04 fedora.box.net certmonger[7845]: Request for certificate to be stored in file “/etc/pki/testcert” rejected by CA.
    >
    > The command issuing the request actually doesn’t give any errors. Accepting the request doesn’t make certmonger notice it.

    The “refresh” command polls for an in-progress request, but at this
    point the daemon’s apparently determined that the request was rejected,
    so it would ignore the “refresh” command. The “resubmit” command might
    work better here.

    Getting more info about the configuration for how the helper’s invoked
    for dogtag-ipa might shed some light on things.

  3. I figured out the problem with NEEDS_GUIDANCE – it seems certmonger doesn’t understand some responses from the dogtag correctly. I got proper responses, but certmonger got tripped by extra blank line somewhere.

    I’ve updated the setup, and now certmonger communicates fine with the CA instance, but this time it has issues fetching the certificate (again some parsing issues). Hopefully it will be fixed soon.

  4. The parsing logic was overhauled for certmonger 0.77, and there are additions to the more generic dogtag-submit helper coming in 0.78 to better support supplying the right information when the server profile expects the client to authenticate in some way. Just in case, though, if you’ve captured the server response, and can either add it to a ticket at https://fedorahosted.org/certmonger/newticket, or drop me a copy in email, I’ll likely turn it into sample data for the self-tests, because I’m keen on making it work for your case.

    Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *