On 08/08/2014 11:17 AM, brendan kearney wrote:


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).

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?


Most clients will also do the additional step of matching the hostname in the cert against the originally given hostname. For example, with ldapsearch:

ldapsearch -xLLLZZ -h hostname ...

This will fail if the server cert for hostname has "cn=hostname.domain.tld"

On Aug 8, 2014 1:03 PM, "Rich Megginson" <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

    On 08/08/2014 10:56 AM, brendan kearney wrote:

    Arent all of those lookups done in dns?


    Yes.

    Wouldnt that mean hostnames being fqdn's is irrelevant?


    Not sure what you mean.

    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.

    On Aug 8, 2014 12:11 PM, "Rich Megginson" <rmegg...@redhat.com
    <mailto:rmegg...@redhat.com>> wrote:

        On 08/08/2014 08:57 AM, brendan kearney wrote:

        Kerberos is dependent on A records in dns.  The instance (as
        in principal/instance@REALM) should match the A record in dns.

        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.

        This seems to be an artificial requirement in FreeIPA that
        is wrong.


        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.

        On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa"
        <bruno-barb...@prodesan.com.br
        <mailto:bruno-barb...@prodesan.com.br>> wrote:

            Hello everyone,

            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 "server.example.com
            <http://server.example.com>". 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:

            ____________

            [root@server ~]# hostname
            server
            [root@server ~]# hostname -f
            server.example.com <http://server.example.com>
            [root@server ~]# ipa-client-install
            Discovery was successful!
            Hostname: server.example.com <http://server.example.com>
            Realm: EXAMPLE.COM <http://EXAMPLE.COM>
            DNS Domain: example.com <http://example.com>
            IPA Server: ipa01.example.com <http://ipa01.example.com>
            Base DN: dc=example,dc=com

            Continue to configure the system with these values? [no] yes
            User authorized to enroll computers: admin
            Synchronizing time with KDC...
            Unable to sync time with IPA NTP Server, assuming the
            time is in sync. Please check that port 123 UDP is opened.
            Password for ad...@example.com <mailto:ad...@example.com>:
            Joining realm failed: The hostname must be
            fully-qualified: server
            Installation failed. Rolling back changes.
            IPA client is not configured on this system.

            ________________

            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.

            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.

            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."
            I've also found this message
            http://osdir.com/ml/freeipa-users/2012-03/msg00006.html
            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?

            Thank you and sorry for the wall of a text.

            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).

            RPMs:
            libipa_hbac-1.9.2-129.el6_5.4.x86_64
            libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
            python-iniparse-0.3.1-2.1.el6.noarch
            ipa-pki-common-theme-9.0.3-7.el6.noarch
            ipa-pki-ca-theme-9.0.3-7.el6.noarch
            ipa-admintools-3.0.0-37.el6.x86_64
            ipa-server-selinux-3.0.0-37.el6.x86_64
            ipa-server-3.0.0-37.el6.x86_64
            ipa-python-3.0.0-37.el6.x86_64
            ipa-client-3.0.0-37.el6.x86_64



            --
            Manage your subscription for the Freeipa-users mailing list:
            https://www.redhat.com/mailman/listinfo/freeipa-users
            Go To http://freeipa.org for more info on the project





        --
        Manage your subscription for the Freeipa-users mailing list:
        https://www.redhat.com/mailman/listinfo/freeipa-users
        Go To http://freeipa.org for more info on the project



-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to