Discussion:
certificate warnings
Brett @Google
2010-03-16 09:45:25 UTC
Permalink
Hello,

Is there any way of supressing the SSL warning/error "TLS: hostname (XXXXX)
does not match common name in certificate" for a syncrepl client ?

This error is being returned by a syncrepl client which is negotiating SSL
talking to a syncrepl server by using it's (actual / real) server name, but
as the server name returns a certificate based on its (external / content
switch) server name, the ssl library on the client waits for a randomly long
time, and then returns the error above as the cert returned does not exactly
match the hostname configured in the provider="" line, in the syncrepl
client configuration.

If it's indeed a warning, then the sycrepl client should ignore it, but it
does not, so effectively it is an error as it causes the syncrepl client to
abort it's connection.

A hack might be to add the "external" name to /etc/hosts on each syncrepl
client with the correct ip for each syncrepl server, but was hoping for
something better.

Cheers
Brett
Quanah Gibson-Mount
2010-03-16 19:37:54 UTC
Permalink
Post by Brett @Google
A hack might be to add the "external" name to /etc/hosts on each syncrepl
client with the correct ip for each syncrepl server, but was hoping for
something better.
Your cert should have a subjectAltName for its internal name.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Philip Guenther
2010-03-16 20:09:32 UTC
Permalink
Post by Brett @Google
Is there any way of supressing the SSL warning/error "TLS: hostname
(XXXXX) does not match common name in certificate" for a syncrepl
client?
This error is being returned by a syncrepl client which is negotiating
SSL talking to a syncrepl server by using it's (actual / real) server
name, but as the server name returns a certificate based on its
(external / content switch) server name, the ssl library on the client
waits for a randomly long time, and then returns the error above as the
cert returned does not exactly match the hostname configured in the
provider="" line, in the syncrepl client configuration.
Right answer: give (each) server a cert which has a subjectAltName
extension that includes its real name.
Post by Brett @Google
If it's indeed a warning, then the sycrepl client should ignore it, but
it does not, so effectively it is an error as it causes the syncrepl
client to abort it's connection.
I-Don't-Really-Care-About-Security Answer: set the tls_reqcert suboption
on the syncrepl option to disable checking of connected to URL against the
returned certificate's names. Or, the better way to do that (but still
insecure) is to configure it to use an anonymous cipher-suite, thereby
saving a bunch of crypto during TLS handshakes.


Philip Guenther
Dieter Kluenter
2010-03-16 20:53:57 UTC
Permalink
Am Tue, 16 Mar 2010 19:45:25 +1000
Post by Brett @Google
Hello,
Is there any way of supressing the SSL warning/error "TLS: hostname
(XXXXX) does not match common name in certificate" for a syncrepl
client ?
This error is being returned by a syncrepl client which is
negotiating SSL talking to a syncrepl server by using it's (actual /
real) server name, but as the server name returns a certificate based
on its (external / content switch) server name, the ssl library on
the client waits for a randomly long time, and then returns the error
above as the cert returned does not exactly match the hostname
configured in the provider="" line, in the syncrepl client
configuration.
If it's indeed a warning, then the sycrepl client should ignore it,
but it does not, so effectively it is an error as it causes the
syncrepl client to abort it's connection.
A hack might be to add the "external" name to /etc/hosts on each
syncrepl client with the correct ip for each syncrepl server, but was
hoping for something better.
You may either configure syncrepl with 'tls_reqcert=never, which would
not be a wise decission, or add a subjectAltName value to the host
certificate.

-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
Brett Maxfield
2010-03-17 00:30:29 UTC
Permalink
Post by Dieter Kluenter
Am Tue, 16 Mar 2010 19:45:25 +1000
Post by Brett @Google
Hello,
Is there any way of supressing the SSL warning/error "TLS: hostname
(XXXXX) does not match common name in certificate" for a syncrepl
client ?
This error is being returned by a syncrepl client which is
negotiating SSL talking to a syncrepl server by using it's (actual /
real) server name, but as the server name returns a certificate based
on its (external / content switch) server name, the ssl library on
the client waits for a randomly long time, and then returns the error
above as the cert returned does not exactly match the hostname
configured in the provider="" line, in the syncrepl client
configuration.
If it's indeed a warning, then the sycrepl client should ignore it,
but it does not, so effectively it is an error as it causes the
syncrepl client to abort it's connection.
A hack might be to add the "external" name to /etc/hosts on each
syncrepl client with the correct ip for each syncrepl server, but was
hoping for something better.
You may either configure syncrepl with 'tls_reqcert=never, which would
not be a wise decission, or add a subjectAltName value to the host
certificate.
I tried tls_reqcert=never but i stll got the warning. It's the
syncrepl client's ssl library which has an issue with the syncrepl
client's server certificate.

I'm thinking maybe having either a subjectAltName or havimg a non-ssl
listener just for syncrepl (with fw rules) might be the trick.

Cheers
Brett

Owen Marshall
2010-03-16 19:53:35 UTC
Permalink
Post by Brett @Google
A hack might be to add the "external" name to /etc/hosts on each
syncrepl client with the correct ip for each syncrepl server, but was
hoping for something better.
You should be able to use subjectAltName to get the additional name in
the certificate.

http://www.openldap.org/faq/data/cache/185.html

--
Owen Marshall
FacilityONE
***@facilityone.com | (502) 805-2126
Dan Pritts
2010-03-16 20:02:42 UTC
Permalink
Post by Brett @Google
Is there any way of supressing the SSL warning/error "TLS: hostname (XXXXX)
does not match common name in certificate" for a syncrepl client ?
This error is being returned by a syncrepl client which is negotiating SSL
talking to a syncrepl server by using it's (actual / real) server name, but
Interesting -

I was expecting to have this problem when I set up syncrepl here
recently, using the RHEL5 openldap 2.3 builds, but it "just worked."

I do get cert mismatch errors from the command line clients.

danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224

Internet2 Spring Member Meeting
April 26-28, 2010 - Arlington, Virginia
http://events.internet2.edu/2010/spring-mm/
Brett Maxfield
2010-03-16 23:19:46 UTC
Permalink
Post by Dan Pritts
I was expecting to have this problem when I set up syncrepl here
recently, using the RHEL5 openldap 2.3 builds, but it "just worked."
I do get cert mismatch errors from the command line clients.
I only get this error as there is only one "server" externally, but
the traffic is internally spread to several servers for redundancy,
via a hw content switch.

So the servers have a mild identity chrisis due to end users and
syncrepl using the same ip but having conflicting or apparently
different server names.

I think there a several options available given the suggestions made,
much appreciated guys.

Cheers
Brett
Aaron Richton
2010-03-17 03:00:22 UTC
Permalink
Post by Brett @Google
A hack might be to add the "external" name to /etc/hosts on each
syncrepl client with the correct ip for each syncrepl server, but was
hoping for something better.
Proper answers for the scenario you set out have already been discussed,
but on this "change the scenario" front, I might also suggest connecting
to the external name on the external IP. Of course you'll eat some switch
resources and might need to consider your topology/ACLs (for both OpenLDAP
and the network) to keep things secure, but that's all one-time
investment. Once completed, your current and future consumers enjoy a
config that makes a lot more sense to the human eye moving forward.
Loading...