Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Geoffrey Keating <> Mon, 04 October 2010 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 906273A6FD9 for <>; Mon, 4 Oct 2010 09:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eaD3dbPlBQUk for <>; Mon, 4 Oct 2010 09:17:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 76DC93A6FC5 for <>; Mon, 4 Oct 2010 09:17:30 -0700 (PDT)
Received: by (Postfix, from userid 501) id CDED833D0FD; Mon, 4 Oct 2010 16:18:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Ralph Holz <>
References: <> <>
From: Geoffrey Keating <>
Date: 04 Oct 2010 09:18:24 -0700
In-Reply-To: <>
Message-ID: <m2r5g6j5in.fsf@localhost.localdomain>
Lines: 35
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Oct 2010 16:17:31 -0000

Ralph Holz <> writes:

> Hi,
> > But keep in mind that few TLS clients (such as browsers), currently
> > support "pinning" of PKIX-authenticated server certs, so that on future
> > connects only the very same server cert (with user-authenticated
> > attributes other than DNS f.q.d.n) will be accepted from that server.
> > In is very common misbehaviour in TLS clients to accept arbitrary other
> > server certs on future connects, as long as the DNS f.q.d.n matches.
> I have found during a few tests that some companies which give different
> IPs for the same DNS name also run some servers with different certs
> than the "main one". A closer look at the certs revealed that they had
> been issued for the same domain and had been signed by the same CA, i.
> e. they were perfectly valid. Pinning certs would prohibit this kind of
> behaviour.
> Although I am not sure it is intentional - my thought was that these
> servers were just misconfigured (older cert?), as only very few
> exhibited this behaviour.

Some CAs license their certificates for use on a single server.  If
these companies were using one of these CAs, they may have bought
multiple certificates for the same DNS name.  This might be done even
if the CA doesn't require it, as a security/reliability measure, so
that machines do not need to share private keys.

This can also happen for the same IP address, if it's a load balancer
with several servers behind it.

It can also happen if the systems serve different combinations of DNS
names: one machine serves and another serves both and so they have different certificates.