Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

[zanata-cli] strict hostname checking on newer version with "--disable-ssl-cert" option?

Description

[Background]
OpenStack I18n team uses Zanata as a translation platform: https://translate.openstack.org and current Zanata version for production is 3.7.3, which seems to be relatively old. OpenStack infrastructure team manages all the configurations based on puppet: http://git.openstack.org/cgit/openstack-infra/puppet-zanata and newer version of Zanata (e.g., 3.9.6) needs Java 8 and additional dependencies which has been main obstacles for upgrade. Now many things have been enhanced on development test server: https://translate-dev.openstack.org/ - which runs Zanata 3.9.6 on Xenial (Ubuntu 16.04).

Since https://translate-dev.openstack.org/ environment is for testing purposes, SSL certification is not trusted. Moreover, it actually runs on translate-dev01.openstack.org and translate-dev.openstack.org is a kind of a virtual host - the main purpose of using translate-dev01.openstack.org is to allow more test servers with different depending environment (e.g., OS version, Java version, ...) - https://review.openstack.org/#/c/399789/ .

[Problem]

When I tested zanata-cli command on both 4.1.0 and 3.9.1, 4.1.0 does not work because of strict domain checking. The main error message I think is: "Caused by: javax.net.ssl.SSLException: hostname in certificate didn't match: <translate-dev.openstack.org> != <translate-dev01.openstack.org>".

[Question]

Such kind of strict hostname checking has been applied with some purposes? Note that it would be fine when I change from translate-dev.openstack.org to translate-dev01.openstack.org in both zanata.xml and zanata.ini. I want to ask:

  • whether strict hostname checking is intentional or not

  • Possibility to support less strict hostname checking

Environment

None

Activity

Show:

Sean Flanigan 23 February 2017 at 04:20

I support the idea of using a CA if possible. --disable-ssl-cert is meant to be a temporary workaround only. Using that option could hide problems which will eventually hit the production systems.

However, I don't think a trusted CA will help if the hostname is wrong. That sounds like a problem with the certificate names and/or the DNS alias setup.

However, we might be able to use clientBuilder.hostnameVerifier(NoopHostnameVerifier.INSTANCE) when creating ResteasyClientBuilder for --disable-ssl-cert. (Or AllowAllHostnameVerifier.INSTANCE.)

Former user 23 February 2017 at 00:41

We upgraded/changed some of the library and it's the library that is checking the hostname. Not intentional but more as a side effect.
I am not sure how hard it is to support a less strict hostname checking or whether it is a good idea to do so. If all those servers share a common CA then you can import that CA into truststore so that those server can pass ssl verification.

Former user 22 February 2017 at 21:48


Also, I would recommend to use zanata-cli 3.9 since the server is running on 3.9. There's some functionalities in zanata-cli 4.0 that might not compatible with 3.9 server.

Former user 22 February 2017 at 21:41
Edited


We will investigate on this. There's quite abit of backend changes from 3.9 to 4.0

Details

Assignee

Reporter

Tested Version/s

Priority

More fields

Created 22 February 2017 at 08:36
Updated 23 February 2017 at 04:20