Bug 1114127
| Summary: | RHEL6.5 ipa-server-install fails configuring certificate server instance | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Scott Poore <spoore> |
| Component: | ipa | Assignee: | Martin Kosek <mkosek> |
| Status: | CLOSED WONTFIX | QA Contact: | Namita Soman <nsoman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | Aaron.Boudreaux, abokovoy, alee, dpal, jpazdziora, rcritten |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-01-29 13:21:00 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Scott Poore
2014-06-27 20:14:04 UTC
Note, I got come help from dogtag guys troubleshooting this. Ade noticed that there wasn't a service check between 2/21 pkicreate and 3/21 pkisilent. A check to make sure the service is up and functioning may help here? FYI, I did attempt a workaround like from bug#905064#c16: [root@pit1 install]# cat /usr/bin/pkicreate #!/bin/sh /usr/bin/pkicreate.real "$@" RET=$? sleep 100 exit $RET [root@pit1 install]# ls -l /usr/bin/pkicreate.real -rwxr-xr-x. 1 root root 150749 Sep 3 2013 /usr/bin/pkicreate.real [root@pit1 install]# It paused for the 100 seconds as you can see from the time but, it still failed. So, I'm not sure if there is a usable workaround here. Thoughts? Ok, it looks like Bug 1112581 was really not caused by an interim package error. Ade, please help us with investigation, it looks like the problem is not in a wait for pkicreate (Comment 1). The problem here is the length of the hostname. When we run pkicreate, we create a temporary cert in the certificate database to get SSL kickstarted. I looked on the system and noticed that the cert had not been generated (and therefore SSL connections failed). The command used to create the cert is something like the following: root@pit-scenario2-7244a244-10af-4e0e-ac56-c715e79fd03f-rs-1 ~]# certutil -S -d /tmp/foo -h 'internal' -m 0 -v 12 -x -s 'CN=pit-scenario2-7244a244-10af-4e0e-ac56-c715e79fd03f-rs-1.novalocal,O=2014-06-30 10:24:33' -c 'CN=pit-scenario2-7244a244-10af-4e0e-ac56-c715e79fd03f-rs-1.novalocal,O=2014-06-30 10:24:33' -t 'CTu,CTu,CTu' ... which results in: certutil -s: improperly formatted name: "CN=pit-scenario2-7244a244-10af-4e0e-ac56-c715e79fd03f-rs-1.novalocal,O=2014-06-30 10:24:33" The reason for this is that the CN exceeds 64 characters. According to RFC 5280, the CN cannot exceed 64 characters --> In Appendix A: -- Upper Bounds ub-common-name INTEGER ::= 64 Therefore, this is not a bug in Dogtag. I also found that this is a limit for hostname max length: [root@pit-scenario2-7244a244-10af-4e0e-ac56-c715e79fd03f-rs-1 sysconfig]# getconf HOST_NAME_MAX 64 Since this is a known limit we're hitting for the CN for the cert, as well as a limit for hostname max length. So, I'm closing this one out as NOTABUG. Would it make sense FreeIPA to check the hostname before the server/replica installer is run? This would require just one extra check to hostname validator. It may be beneficial, given how difficult it was to investigate the root cause. Maybe. You're right. It would have helped here. So, reopening so installer can be updated to check hostname length. Thanks Note that while CN is limited to 64 characters, it is not a host name but full FQDN that is passed there. In this particular case hostname is 54 character long but FQDN is 65 characters long, thus it fails. So a check would need to take FQDN and ensure that it is less than 64 characters. Now, this will be a sizable limitation as DNS entries can have 64 character *per label*, not per whole FQDN. I think we may be using RFC5280 wrongly here. It states (and RFC 6818 which is an update to RFC 5280 doesn't change this dramatically): 4.1.2.4 [..] In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in [RFC4519]. The Domain Name System (DNS) provides a hierarchical resource labeling system. This attribute provides a convenient mechanism for organizations that wish to use DNs that parallel their DNS names. I think we should be packing FQDN into domainComponent attribute and use just a host name part for CN. Upstream ticket: https://fedorahosted.org/freeipa/ticket/4415 Looking at nss code, I can see that with the help of bug https://bugzilla.mozilla.org/show_bug.cgi?id=970539 there is a change in upstream libnss to allow CN attribute value to be up to 640 bytes instead of 64. The code otherwise doesn't put any limitation on the CN value. Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux. Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as WONTFIX. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you. Note that you can still track this request or even contribute patches in the referred upstream Trac ticket. We have just run into this issue also. Our short hostname is only 16 characters, but our fully qualified domain name (fqdn) is over the 64 characters. Our fqdn is a valid dns name (both bind dns and rhel 7 gladly accept this fqdn) and the specification also appears to confirm that the fqdn can be over 64 characters (https://stackoverflow.com/questions/32290167/what-is-the-maximum-length-of-a-dns-name https://www.ietf.org/rfc/rfc1035.txt). Debugging the problem was time consuming since the ipa-client-install does not explicitly check for the fqdn length and the error a very low level exception. I request that this issue be reopened for a future release of rhel since not allowing an fqdn longer 64 characters is not the correct behavior. This was addressed upstream in ticket https://pagure.io/freeipa/issue/2018 in IPA 4.8.0+. The default FQDN length is 64 characters. Rob, From the description https://pagure.io/freeipa/issue/2018 does not sound like it solves the problem. That sounds like it is still addressing the max length of the short hostname (i.e a single segment of the dns domain). Our short hostname is only 16 characters so checking the max length of that will still succeeded. However the ipa-client-install fails if the fqdn is longer than 64 characters. Does the resolution to that issue also fix the ipa-client-install to correctly allow fqdn up to 253 characters? I read the description of this issue too quickly. It is referring to ipa-server-install not ipa-client-install. Perhaps I should open a new issue unless this is already resolved in a newer version of redhat idm / freeipa? We are currently using rhel 7.5 with redhat idm 4.5.4. It applies to all hosts created in IPA using the API. It is resolved in RHEL 8. Great! Thanks for the info Rob! |