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
--On Tuesday, March 16, 2010 7:45 PM +1000 "Brett @Google" brett.maxfield@gmail.com wrote:
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
On Tue, 2010-03-16 at 19:45 +1000, Brett @Google wrote:
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 omarshall@facilityone.com | (502) 805-2126
On Tue, Mar 16, 2010 at 07:45:25PM +1000, Brett @Google wrote:
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/
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
On Tue, 16 Mar 2010, Brett @Google wrote:
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.
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
Am Tue, 16 Mar 2010 19:45:25 +1000 schrieb "Brett @Google" brett.maxfield@gmail.com:
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
On 17/03/2010, at 6:53 AM, Dieter Kluenter dieter@dkluenter.de wrote:
Am Tue, 16 Mar 2010 19:45:25 +1000 schrieb "Brett @Google" brett.maxfield@gmail.com:
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
On Tue, 16 Mar 2010, Brett @Google wrote:
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.
openldap-software@openldap.org
-
Aaron Richton -
Brett ＠Google -
Brett Maxfield
-
Dan Pritts -
Dieter Kluenter -
Owen Marshall -
Philip Guenther -
Quanah Gibson-Mount