Quanah Gibson-Mount wrote:
--On Tuesday, May 09, 2017 10:58 PM +0200 Michael Ströder
wrote:
"subjectAltName" means *alternative* name. It is totally correct for
libldap to reject your cert with a hostname mismatch when the cert cn is
incorrect.
Human language can cause misunderstandings. So
--On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu wrote:
No. One or the other must match, but the CN must be an FQDN. The point of
alternatives is to support wildcards, aliases, and non-DNS name forms
(such as IP address).
RFC reference?
Unfortunately, I can't do an IP based cert either
Quanah Gibson-Mount wrote:
> --On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu wrote:
>
>> No. One or the other must match, but the CN must be an FQDN. The point of
>> alternatives is to support wildcards, aliases, and non-DNS name forms
>> (such as IP address).
>
> RFC reference?
RFC 6125
--On Wednesday, May 10, 2017 7:01 PM +0200 Michael Ströder
wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu
wrote:
No. One or the other must match, but the CN must be an FQDN. The point
of alternatives is to support wildcards, aliases, and non-DNS nam
--On Wednesday, May 10, 2017 10:11 AM -0700 Quanah Gibson-Mount
wrote:
RFC 6125 which in turn mentions RFC 4513.
Thanks.
From RFC 6125:
6.4.4. Checking of Common Names
As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers includ
On Wed, May 10, 2017 at 09:32:59AM -0700, Quanah Gibson-Mount wrote:
RFC 6761 specifically notes that "localhost." is in fact a domain name
(Section 6.3). Therefore, my certificates are in fact correct, and
the OpenLDAP code check is indeed a bug.
"localhost." is a perfectly valid FQDN (as is
--On Wednesday, May 10, 2017 10:49 AM -0700 Ryan Tandy
wrote:
On Wed, May 10, 2017 at 09:32:59AM -0700, Quanah Gibson-Mount wrote:
RFC 6761 specifically notes that "localhost." is in fact a domain name
(Section 6.3). Therefore, my certificates are in fact correct, and
the OpenLDAP code check
Quanah Gibson-Mount wrote:
--On Wednesday, May 10, 2017 7:01 PM +0200 Michael Ströder
wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu
wrote:
No. One or the other must match, but the CN must be an FQDN. The point
of alternatives is to support wildcard
Quanah Gibson-Mount wrote:
--On Wednesday, May 10, 2017 10:49 AM -0700 Ryan Tandy wrote:
On Wed, May 10, 2017 at 09:32:59AM -0700, Quanah Gibson-Mount wrote:
RFC 6761 specifically notes that "localhost." is in fact a domain name
(Section 6.3). Therefore, my certificates are in fact correct,
--On Wednesday, May 10, 2017 7:02 PM +0100 Howard Chu wrote:
The point is there is nothing on your machine that says your hostname is
"localhost". Therefore, since the subjectAltName of DNS:localhost doesn't
match any known name for your host, the cert is rejected.
Sure there is, /etc/hosts.
Howard Chu wrote:
> The point is there is nothing on your machine that says your hostname is
> "localhost".
> Therefore, since the subjectAltName of DNS:localhost doesn't match any known
> name for
> your host, the cert is rejected.
The machine's hostname is completely irrelevant.
The TLS hostn
Howard Chu wrote:
> Wrong. The FQDN of the system is the entire point of this discussion.
^^
No! No! No!
Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
In testing a suggestion from Howard, it appears that OpenLDAP code is
broken for IP based certs (where the IP: is in subject Alternative
Name), as it does a hostname lookup prior to validating the cert. This is
trivially demonstrable using a cert with:
X509v3 Subject Alternative N
Quanah Gibson-Mount wrote:
> Attempting to connect via ldapsearch to ldap://127.0.0.1 and initiate
> startTLS will
> fail, as the IP gets mapped to "localhost", and then the FQDN check fails.
Yes, this is a bug. Especially since the mapping to "localhost" does not have a
trustable
source for thi
--On Wednesday, May 10, 2017 11:19 PM +0200 Michael Ströder
wrote:
Quanah Gibson-Mount wrote:
Attempting to connect via ldapsearch to ldap://127.0.0.1 and initiate
startTLS will fail, as the IP gets mapped to "localhost", and then the
FQDN check fails.
Yes, this is a bug. Especially since t
15 matches
Mail list logo