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.
Click view certificates and then “Your Certificates” on that panel, and finally click the Import Button.
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.
You can avoid using a browser for approval if you use the “pki” command-line utility that was added in Dogtag 10. There’s a nice demo video of it in action on the Dogtag wiki:
http://pki.fedoraproject.org/wiki/User_Certificate#Approve_Certificate_Request
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?
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.
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.
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!