<p dir="ltr">Double check your example.  -h means the hostname of the ldap server to connect to and issue your query to.  Man page calls it ldaphost.</p>
<p dir="ltr">I have not run across a client that does cert validation using ldap.  Is that IPA specific?</p>
<p dir="ltr">It seems that a lot of effort is being spent to justify a dependency on fully qualified hostnames, when there is no reason to require it.  In fact, it may even break somethings or even violate some rfc.</p>
<div class="gmail_quote">On Aug 8, 2014 1:43 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 11:17 AM, brendan kearney
      wrote:<br>
    </div>
    <blockquote type="cite">
      <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>
    </blockquote>
    <br>
    Most clients will also do the additional step of matching the
    hostname in the cert against the originally given hostname.  For
    example, with ldapsearch:<br>
    <br>
    ldapsearch -xLLLZZ -h hostname ...<br>
    <br>
    This will fail if the server cert for hostname has
    "cn=hostname.domain.tld"<br>
    <br>
    <blockquote type="cite">
      <div class="gmail_quote">On Aug 8, 2014 1:03 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 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>
    </blockquote>
    <br>
  </div>

</blockquote></div>