Re: Subject Alternative Name in TLS

Re: Subject Alternative Name in TLS - does this work?

To: Howard Chu <hyc@symas.com>

Subject: Re: Subject Alternative Name in TLS - does this work?

From: Erwann Abalea <eabalea@gmail.com>

Date: Mon, 21 Oct 2013 15:04:41 +0200

Cc: Christian Kratzer <ck-lists@cksoft.de>, Christian Kratzer <ck@cksoft.de>, lejeczek <peljasz@yahoo.co.uk>, openldap-technical@openldap.org

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9FFpJzZID5NPSuSAn5/kLYoFYn8oyU+55eQ6aC2hb3Y=; b=ikmYNJFKFaK7OyfVsZSIDSyGYtfsO0Fb6QrdlvXynmN+J02V4f/b9Yg7YUFL/PjGcu SFUSaE5ahoeJi6eBORJYcaVJSVO3drMlkQCRJ70/2KJzHYlzUb7ERlMqk7rXVb/wbFeS c/fn46g6/vnAQTplucIgDFrACWwuvnMnALdueuvn8Ytci6fbz4Tum+7K2bJU9eW7M+de vqukW7ZzHLqiE0fYKcsAm95qEPQ8Dxq40Z3tWkPgpb8w48qC1jiRDCJt11wxmFTjzx5N OBmDO+a45MefByFLCMSQ+Ajj+YbHpRsNA7/kR9vp7yn6SoNEDBYnJpJLUyNhKfayYfD4 1XLA==

In-reply-to: <5264FC1A.70109@symas.com>

References: <52600718.4000807@yahoo.co.uk> <alpine.BSF.2.00.1310181134000.88246@pohjola.cksoft.de> <52610CB7.9080800@yahoo.co.uk> <alpine.BSF.2.00.1310181254500.88246@pohjola.cksoft.de> <526137FB.90408@yahoo.co.uk> <alpine.BSF.2.00.1310181533530.88246@pohjola.cksoft.de> <5264E79B.7050300@yahoo.co.uk> <alpine.BSF.2.00.1310211059040.88246@pohjola.cksoft.de> <5264F369.9040800@yahoo.co.uk> <5264FC1A.70109@symas.com>

2013/10/21 Howard Chu <hyc@symas.com>

lejeczek wrote:

that was me, the way I tried to sing certificate were...
incorrect

apologies and great and many thanks to everybody

I can now ldapsearch on both slapd.domain.local and
slap.domain.external with -ZZZ, all good (only cannot
confirm if CN has to be repeated in subjectAltName as per
Olo's tip, currently it IS repeatedin my cert)

No. The CN does not need to be repeated, anyone who says so is wrong. Other libraries (e.g. old Solaris/Sun/Mozilla LDAP) may have required this but they are defective and obsolete. The Mozilla LDAP SDK has been abandoned, and Solaris 11 now bundles OpenLDAP.

The CN has to be repeated. Newer libraries ignore anything contained in the CN if the SAN is populated. Antique PKI usages use CN to store FQDN and/or IP adresses (which is bad in itself), and this can't work with NameConstraints.

See RFC2830 (section 3.6) and RFC4513 (section 3.1.3) for LDAP, see RFC2818 (section 3.1) for HTTP, see RFC6125 for a broader view. Then see browsers root programs and CABForum Baseline Requirements (sections 9.2.1 and 9.2.2) for rules applied to public CAs (and reflected in the corresponding TLS toolkits).

--
Erwann.