I would like to teach Cockpit to use a FreeIPA SSL cert instead of a locally generated self-signed one for its web server (which uses principal HTTP/x0.cockpit.lan@COCKPIT.LAN, so that enrolling into a realm will get a proper https by default.
HTTP/x0.cockpit.lan@COCKPIT.LAN
I've read various documentation: - https://www.freeipa.org/page/PKI - https://blog.christophersmart.com/2014/08/24/creating-certs-and-keys-for-services-using-freeipa-dogtag/ - https://www.freeipa.org/page/V4/Certificate_Profiles#CLI
but still can't get this to work (f0.cockpit.lan is the IPA server, x0.cockpit.lan the enrolled client):
$ klist 22.05.2018 06:02:03 23.05.2018 06:01:45 HTTP/f0.cockpit.lan@COCKPIT.LAN 22.05.2018 06:01:45 23.05.2018 06:01:45 krbtgt/COCKPIT.LAN@COCKPIT.LAN $ ipa service-show HTTP/x0.cockpit.lan@COCKPIT.LAN Principal name: HTTP/x0.cockpit.lan@COCKPIT.LAN Principal alias: HTTP/x0.cockpit.lan@COCKPIT.LAN Keytab: True Managed by: x0.cockpit.lan $ sudo ipa-getcert request -f /tmp/cockpit-ws.crt -k /tmp/cockpit-ws.key -K HTTP/x0.cockpit.lan -N CN=x0.cockpit.lan,O=COCKPIT.LAN -w -v [sudo] password for admin@cockpit.lan: New signing request "20180522100145" added. State NEWLY_ADDED_READING_KEYINFO, stuck: no. State SUBMITTING, stuck: no. State CA_REJECTED, stuck: yes. $ sudo ipa-getcert list Number of certificates and requests being tracked: 1. Request ID '20180522100145': status: CA_REJECTED ca-error: Server at https://f0.cockpit.lan/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Principal 'HTTP/x0.cockpit.lan@COCKPIT.LAN' is not permitted to use CA 'ipa' with profile 'caIPAserviceCert' for certificate issuance.). stuck: yes key pair storage: type=FILE,location='/tmp/cockpit-ws.key' certificate: type=FILE,location='/tmp/cockpit-ws.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes
Now there are the ipa caacl-* commands, but it seems that there is a default "all allowed" rule in place already:
ipa caacl-*
$ ipa caacl-find ---------------- 1 CA ACL matched ---------------- ACL name: hosts_services_caIPAserviceCert Enabled: TRUE Host category: all Service category: all
I also tried to explicitly add the profile or the host, but the above rule already includes that:
$ ipa caacl-add-profile hosts_services_caIPAserviceCert --certprofiles=caIPAserviceCert ACL name: hosts_services_caIPAserviceCert Enabled: TRUE Host category: all Service category: all Profiles: caIPAserviceCert Failed profiles: member Certificate Profile: caIPAserviceCert: This entry is already a member $ ipa service-add-host --hosts=`hostname -f` HTTP/`hostname -f` Principal name: HTTP/x0.cockpit.lan@COCKPIT.LAN Principal alias: HTTP/x0.cockpit.lan@COCKPIT.LAN Managed by: x0.cockpit.lan Failed managedby: member host: x0.cockpit.lan: This entry is already a member
Is that even the right approach to take?
Thank you in advance!
Fedora 28 freeipa-client-4.6.90.pre1-6.1.fc28.x86_64
One command that at least did something was:
$ ipa caacl-add-ca hosts_services_caIPAserviceCert --cas=ipa ACL name: hosts_services_caIPAserviceCert Enabled: TRUE Host category: all Service category: all CAs: ipa Profiles: caIPAserviceCert ------------------------- Number of members added 1 -------------------------
But after that, ipa-getcert request still fails on the same error (Principal 'HTTP/x0.cockpit.lan@COCKPIT.LAN' is not permitted to use CA 'ipa' with profile 'caIPAserviceCert' for certificate issuance.)
ipa-getcert request
Principal 'HTTP/x0.cockpit.lan@COCKPIT.LAN' is not permitted to use CA 'ipa' with profile 'caIPAserviceCert' for certificate issuance.
Seems to be a duplicate of https://pagure.io/freeipa/issue/7466. I will close the ticket now, but if it turns out to be something else, please reopen it.
@martinpitt there is a build in f28 updates-testing repo that includes the fix: https://bodhi.fedoraproject.org/updates/FEDORA-2018-93dfeefc68.
Metadata Update from @ftweedal: - Issue close_status updated to: duplicate
Confirmed, with the pre2 version, ipa-getcert request now works correctly. Thank you!
Do you see any downside with cockpit (opportunistically) calling that when enrolling into a domain, so that its web server has a FreeIPA-signed certificate instead of the default self-signed one?
@martinpitt it seems like a valid use case; I don't know enough about Cockpit to say anything more specific, though.