Bug 1400529 - cert-request is not aware of Kerberos principal aliases
Summary: cert-request is not aware of Kerberos principal aliases
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Abhijeet Kasurde
Depends On:
TreeView+ depends on / blocked
Reported: 2016-12-01 12:37 UTC by Thorsten Scherf
Modified: 2017-08-01 09:44 UTC (History)
7 users (show)

Fixed In Version: ipa-4.5.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-01 09:44:33 UTC
Target Upstream Version:

Attachments (Terms of Use)
console.log (6.58 KB, text/plain)
2017-06-08 09:58 UTC, Abhijeet Kasurde
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2304 normal SHIPPED_LIVE ipa bug fix and enhancement update 2017-08-01 12:41:35 UTC

Description Thorsten Scherf 2016-12-01 12:37:57 UTC
This bug is created as a clone of upstream ticket:

It is currently not possible to use `ipa cert-request` to issue certificates for hosts/service using their principal aliases (see the minimal reproducer below). 

[root@master1 ~]# ipa service-add test/`hostname`
Added service "test/master1.ipa.test@IPA.TEST"
  Principal name: test/master1.ipa.test@IPA.TEST
  Principal alias: test/master1.ipa.test@IPA.TEST
  Managed by: master1.ipa.test
[root@master1 ~]# ipa service-add-principal test/`hostname` test2/`hostname`
Added new aliases to the service principal "test/master1.ipa.test@IPA.TEST"
  Principal name: test/master1.ipa.test@IPA.TEST
  Principal alias: test2/master1.ipa.test@IPA.TEST, test/master1.ipa.test@IPA.TEST
[root@master1 ~]# kinit -kt /etc/krb5.keytab  host/`hostname`
[root@master1 ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_50GX1N0
Default principal: host/master1.ipa.test@IPA.TEST

Valid starting       Expires              Service principal
09/05/2016 10:44:40  09/06/2016 10:44:40  krbtgt/IPA.TEST@IPA.TEST

[root@master1 ~]# openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -subj '/CN=master1.ipa.test/subjectAltName=DNS.1=master1.ipa.test' -out test.csr
Generating a 2048 bit RSA private key
writing new private key to 'test2service.key'

[root@master1 ~]# ipa cert-request test.csr --principal test2/`hostname`
ipa: ERROR: The principal for this request doesn't exist.
[root@master1 ~]# ipa cert-request test.csr --principal test2/`hostname`@IPA.TEST
ipa: ERROR: The principal for this request doesn't exist.

[root@master1 ~]# ipa cert-request test.csr --principal test/`hostname`@IPA.TEST
  Issuing CA: ipa
  Certificate: MIIEA...
  Subject: CN=master1.ipa.test,O=IPA.TEST
  Issuer: CN=Certificate Authority,O=IPA.TEST
  Serial number: 11
  Serial number (hex): 0xB

The code should be updated to perform LDAP search for recipients by supplied 'krbprincipalname' value and then perform SAN DNS name checks and other operations against the list Principal objects returned by the search.

Comment 1 Martin Babinsky 2016-12-09 16:49:20 UTC
Fixed upstream

Comment 6 Abhijeet Kasurde 2017-05-29 13:47:44 UTC
Marking BZ as failedQA as fix is not ported in RHEL IPA build.

Comment 7 Martin Babinsky 2017-05-30 07:57:31 UTC
When pushing the patch I forgot to include the commit in ipa-4-5 branch to this BZ, that's why it was not picked up during build process.

Pavel can you please include it in the next build of ipa? Sorry for the inconveniece.

Fixed upstream:


Comment 8 Martin Babinsky 2017-05-30 08:19:09 UTC
Disregard my previous comment, the fix was pushed to master before ipa-4-5 was even forked so it should be there.

In that case this seems to be either a legitimate bug or an issue in tests (given that the fix was provided upstream tests that are green).

Fraser, can you investigate this with Abhijeet?

Comment 9 Pavel Vomacka 2017-05-30 10:42:52 UTC
As Martin wrote above, the fix is already in IPA build. So the issue will be caused by something else.

Comment 10 Fraser Tweedale 2017-05-30 11:22:12 UTC

The --principal option to `ipa cert-request` must be the canonical
princpial name.  What this change does is allows information in the
CSR to match the principal aliases.  There is a separate ticket[1]
(not yet implemented) to allow principal aliases to be used as the
--principal argument.

[1] https://pagure.io/freeipa/issue/6531

So to test this, use the canonical princpial name as the --principal
argument, but include principal aliases in the CSR.  e.g., try the
following combinations, for appropriate instantiations of

1) Canonical principal name "test/DOMAIN", CN = "OTHERDOMAIN"

2) Canonical principal name "test/DOMAIN", CN = "DOMAIN",
   SAN dnsName = "OTHERDOMAIN"

Note that when comparing SERVICE principal names, because the
CN and SAN dnsName are merely domain names, we prepend
THE SAME SERVICE PREFIX as appears in the canonical princpial.
Therefore if the canonical principal name is test/DOMAIN,
and the CN is OTHERDOMAIN, we look for "test/OTHERDOMAIN"
among the principal alises.

Another IMPORTANT note: your steps for creating a CSR with the
subjectAltName extension are wrong -- you cannot put it in the
Subject Name (-subj option) as you have done.

Instead, create a config file like the below and supply the
'-config FILENAME' option to `openssl req`.

[ req ]
prompt = no
encrypt_key = no

distinguished_name = dn
req_extensions = exts

[ dn ]
commonName = "testhost1.ipa.local"

[ exts ]

Hope that helps!

Comment 22 Abhijeet Kasurde 2017-06-08 09:57:36 UTC
Verified using IPA server version:: ipa-server-4.5.0-16.el7.x86_64

Marking BZ as verified. See attachment for console.log.

Comment 23 Abhijeet Kasurde 2017-06-08 09:58:10 UTC
Created attachment 1286095 [details]

Comment 25 errata-xmlrpc 2017-08-01 09:44:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.