<p dir="ltr">The cert should have the fqdn, just like the kerberos instance, but the hostname is not required to be fq'd. The lookup of a short name, as well as and more specifically the IP, in dns will result in the fqdn being returned by dns (the short name resolution being affected by domain and search directives in resolv.conf and the origin directive in dns if either of those are absent).</p>
<p dir="ltr">Back to the point, dns lookup for cert matching is not dependent on hostnames. PTR lookups will always return fqdns, so a dependency on fqdns as hostnames is artificial, no?</p>
<div class="gmail_quote">On Aug 8, 2014 1:03 PM, "Rich Megginson" <<a href="mailto:rmeggins@redhat.com">rmeggins@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 08/08/2014 10:56 AM, brendan kearney
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Arent all of those lookups done in dns?</p>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote type="cite">
<p dir="ltr">Wouldnt that mean hostnames being fqdn's is
irrelevant? </p>
</blockquote>
<br>
Not sure what you mean.<br>
<br>
I guess if you issued your server certs with a subject DN of
"cn=hostname", instead of "cn=hostname.domain.tld", and you had the
DNS PTR lookups configured so that w.x.y.z returned "hostname"
instead of "hostname.domain.tld", then TLS/SSL would work.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">On Aug 8, 2014 12:11 PM, "Rich Megginson"
<<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 08/08/2014 08:57 AM, brendan kearney wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Kerberos is dependent on A records in dns.
The instance (as in principal/instance@REALM) should
match the A record in dns.</p>
<p dir="ltr">There is absolutely no Kerberos dependency on
hostnames being fully qualified. I have all my devices
named with short names and I have no issues with
Kerberos ticketing.</p>
<p dir="ltr">This seems to be an artificial requirement in
FreeIPA that is wrong.</p>
</blockquote>
<br>
The other hostname requirement is for TLS/SSL, for MITM
checking. By default, when an SSL server cert is issued,
the subject DN contains cn=fqdn as the leftmost component.
clients use this fqdn to verify the server. That is, client
knows the IP address of the server - client does a reverse
lookup (i.e. PTR) to see if the server returned by that
lookup matches the cn=fqdn in the server cert. This
requires reverse lookups are configured and that the fqdn is
the first name/alias returned.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">On Aug 8, 2014 8:54 AM, "Bruno
Henrique Barbosa" <<a href="mailto:bruno-barbosa@prodesan.com.br" target="_blank">bruno-barbosa@prodesan.com.br</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-family:tahoma,new york,times,serif;font-size:12pt;color:#000000">Hello
everyone,<br>
<br>
I'm running through an issue where an application
needs its server's hostname to be in short name
format, such as "server" and not "<a href="http://server.example.com" target="_blank">server.example.com</a>".
When I started deploying FreeIPA in the very
beginning of this year, I remember I couldn't
install freeipa-client with a bare "ipa-client
install", because of this:<br>
<br>
____________<br>
<br>
[root@server ~]# hostname<br>
server<br>
[root@server ~]# hostname -f<br>
<a href="http://server.example.com" target="_blank">server.example.com</a><br>
[root@server ~]# ipa-client-install<br>
Discovery was successful!<br>
Hostname: <a href="http://server.example.com" target="_blank">server.example.com</a><br>
Realm: <a href="http://EXAMPLE.COM" target="_blank">EXAMPLE.COM</a><br>
DNS Domain: <a href="http://example.com" target="_blank">example.com</a><br>
IPA Server: <a href="http://ipa01.example.com" target="_blank">ipa01.example.com</a><br>
Base DN: dc=example,dc=com<br>
<br>
Continue to configure the system with these
values? [no] yes<br>
User authorized to enroll computers: admin<br>
Synchronizing time with KDC...<br>
Unable to sync time with IPA NTP Server, assuming
the time is in sync. Please check that port 123
UDP is opened.<br>
Password for <a href="mailto:admin@EXAMPLE.COM" target="_blank">admin@EXAMPLE.COM</a>:
<br>
Joining realm failed: The hostname must be
fully-qualified: server<br>
Installation failed. Rolling back changes.<br>
IPA client is not configured on this system.<br>
<br>
________________<br>
<br>
So, using the short name as hostname didn't work
for install, I then make it like "ipa-client
install --hostname=`hostname -f` --mkhomedir -N",
and it installs and works like a charm, BUT it
updates the machine's hostname to FQDN.<br>
<br>
What I tested and, at first, worked: after
deploying and ipa-client installation with those
parameters which work, renaming the machine back
to a short name AT FIRST is not causing any
problems. I can login with my ssh rules perfectly,
but I don't find any IPA technical docs saying it
will/won't work if I change the hostname back to
short name and not FQDN.<br>
<br>
Searching for it, I found on RedHat guide: "The
hostname of a system is critical for the correct
operation of Kerberos and SSL. Both of these
security mechanisms rely on the hostname to ensure
that communication is occurring between the
specified hosts."<br>
I've also found this message <a href="http://osdir.com/ml/freeipa-users/2012-03/msg00006.html" target="_blank">http://osdir.com/ml/freeipa-users/2012-03/msg00006.html</a>
which seems to be related to my case, but what I
need to know is: where does it state FQDN is a
mandatory requirement in order to FreeIPA to work
and/or is there anything else (a patch, update,
whatever) to solve this issue, so I don't need to
change my applications?<br>
<br>
Thank you and sorry for the wall of a text.<br>
<br>
PS: Enviroment is CentOS 6.5, in both IPA server
and client. DNS is not the same server as IPA (it
forwards to a Windows DC).<br>
<br>
RPMs:<br>
libipa_hbac-1.9.2-129.el6_5.4.x86_64<br>
libipa_hbac-python-1.9.2-129.el6_5.4.x86_64<br>
python-iniparse-0.3.1-2.1.el6.noarch<br>
ipa-pki-common-theme-9.0.3-7.el6.noarch<br>
ipa-pki-ca-theme-9.0.3-7.el6.noarch<br>
ipa-admintools-3.0.0-37.el6.x86_64<br>
ipa-server-selinux-3.0.0-37.el6.x86_64<br>
ipa-server-3.0.0-37.el6.x86_64<br>
ipa-python-3.0.0-37.el6.x86_64<br>
ipa-client-3.0.0-37.el6.x86_64<br>
<br>
<br>
</div>
</div>
<br>
--<br>
Manage your subscription for the Freeipa-users mailing
list:<br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a href="http://freeipa.org" target="_blank">http://freeipa.org</a>
for more info on the project<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div>
<br>
--<br>
Manage your subscription for the Freeipa-users mailing list:<br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a href="http://freeipa.org" target="_blank">http://freeipa.org</a> for more info on the
project<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>