Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1146143
Description of problem: I tried to issue a certificate for a remote server management console (HP iLO 2 to be precise) and I didn't succeed because IPA refuses to sign a .csr that the device generates. The device seems to be configured correctly (ILO 2 Subsystem Name: <base_hostname>, Domain Name: <idm_domain>) yet it generates .csr with this subject: Subject: C=US, ST=Texas, L=Houston, O=Hewlett-Packard Development Company, OU=ISS, CN=<base_hostname> And IPA refuses (rightly so) to issue a certificate: "Insufficient access: hostname in subject of request 'spice-dl380-01-mgmt' does not match principal hostname 'spice-dl380-01-mgmt.spice.brq.redhat.com'" with options Retry and Cancel. IMO there should also be another option: override CN with host FQDN (or possibly IP) in the Subject line Version-Release number of selected component (if applicable): ipa-server-3.0.0-37.el6.x86_64 How reproducible: always Steps to Reproduce: 1. create a Host in IPA web UI 2. generate a .csr request with just basename as a CN 3. try to issue a certificate for the request Actual results: the attempt is flat-out denied Expected results: an option to issue cert with CN=FQDN instead of CN=base_hostname is offered Additional info:
Assigning to Fraser for now, as a 4.2 stretch goal.
Moving to 4.3, we are too close to 4.2 deadline to be able to handle this stretch RFE.
Metadata Update from @jcholast: - Issue set to the milestone: FreeIPA 4.5 backlog
This might be resolve now with support for Kerberos principal aliases when validating requests. I'll try to confirm soon and if so we can close this.
Metadata Update from @ftweedal: - Issue close_status updated to: None
Yes, you can do it with Kerberos principal aliases. If you want to issue a cert for principal host/shortname.example.com@EXAMPLE.COM with CN=shortname, just add a Kerberos principal alias:
host/shortname.example.com@EXAMPLE.COM
CN=shortname
ipa host-add-principal shortname.example.com 'host/shortname'
Then the certificate request will be allowed.
But this does not result in overriding the shortname with the FQDN in the issued cert. So I will leave this open.
Login to comment on this ticket.