-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to configure hostname verification in Zuul now? #1057
Comments
Hi on my project we switch all the yService platform to ssl and, haw to say it, it was not a funny game. My advice would be to avoid disabling hostname certification because it's just pushing the sandbox a bit further. We solve this by creating a shared keystore for dev environment, then we created a self-signed certificate for all dev hosts (with hostname aliases) then reading spring-boot documentation it is easiest to provide custom keystore, aliases, bla bla ) Regards |
Thanks for the suggestion @ouaibsky. Yes I already am using a self-signed certificate and customizing the *stores, etc. I could probably create the additional host aliases for dev like this, but I'm also concerned I'm going to run into a similar (but slightly different) problem with our production configuration which uses consul service discovery. Service names are resolved into host ip:port rather than a hostname and won't match the certificate as the IPs are dynamic in our environment (docker-based). |
Your production concerns sounds different Christophe |
We aren't actually registering in consul with the spring stack, it's being done by mesos/marathon. I'll have to look if domain names can be provided. Thanks. |
When you are using the simpleHost rules you can have a look here: This is the commit to disable hostname verification in a simple zuul example. |
@pcornelissen I tried a similar approach, but it didn't work for me. Did this work for you at runtime (beyond the simple mock test)? I ran into a couple issues. The first was my bean for simpleHostRoutingFilter was being overridden/replaced by the one from ZuulProxyConfiguration, which I was able to overcome by extending and excluding it. The second was that it was still actually doing hostname verification, I believe because of this line in SimpleHostRoutingFilter (where the SSLConnectionSocketFactory constructor needs the hostnameverifier passed in):
|
The ssl problem was gone but the while routing died :-( |
@pcornelissen Ya, the SimpleHostRoutingFilter is not very extension-friendly. I ended up (for now), just copying the class into my zuul project, and editing it. My edits were 2 one-liners. First in the newClient() method, I added this to the builder: Then in the newConnectionManager method, I replaced the registry https line like this: I missed the second change in my attempt to override and extend SimpleHostRoutingFilter, so perhaps that approach would work if you want to try. You can use an extension approach like in |
I'll try to work on a PR for spring-cloud-netflix to resolve this properly hopefully this weekend |
Adds property zuul.sslHostnameValidationEnabled to be able to disable the hostname validation in the simpleHostRoutingFilter fixes gh-1057
@pcornelissen @cah-oster since 1.2.0 isn't out yet, and I need to get this to work now while using the released 1.1.13/14 line, I am trying what you did above (copy the class into my local project and add the support there).
Doing so still does not seem to work for me, I constantly am getting errors like the below. When I step in the SocketFactory in this thread, is still using the
|
@bitsofinfo This fix was actually in 1.1.3, and rolled up into spring-cloud Brixton.SR2. I was able to remove my hack, move to Brixton.SR2, just set this in my application.properties:
1.1.4 and Brixton.SR3 are now also available which should work as well. |
hmm, Im running with SR3 and still getting the above kind of error with
Note the thread stack above, this is originating from a thread invoking Also @cah-oster any thought to allowing someone to provide a custom HostnameVerifier rather than the all or nothing with the NoOp one? I have a case where I only want to provide an exception for one known CN on a specific cert, all the rest can be deferred to the normal rules in apache's default BrowserCompatHostnameVerifier, but this solution is just all or nothing. |
|
k, so perhaps its related to Netflix/eureka#812 ? |
Apologies for posting on an old issue (and I can create a new issue if necessary), but @spencergibb how would I configure hostname validation on the ribbon routing filter? |
I found an example in the comments of #1776 |
spring-cloud-netflix-core:1.1.0.RELEASE |
|
I've been using Zuul with ribbon and SSL in version 1.0.6.RELEASE and tried upgrading to 1.1.0.RELEASE and run into hostname verification failures in my tests which use a localhost certificate for several hostnames. There was an earlier discussion on how to disable hostname verification here (#333 (comment)) but those facilities are no longer present in 1.1.0.RELEASE. What is the current preferred way to configure the SSL settings for zuul's use of ribbon-discovered clients?
The text was updated successfully, but these errors were encountered: