If no objections, I'll be proceeding on adding a client parameter to turn off the CN checking, and reactivating the CN check as the default.
Glen Am Mittwoch, den 26.03.2008, 05:12 -0400 schrieb Glen Mazza: > Team, > > There is apparently a default check in Java to make sure that the SSL > certificate Common Name (CN) matches that of the https:// URL hostname > when making an SSL-based web call. Metro does not disable that > check[1], instead it provides its users a standard workaround during > development, etc., should they wish to use "localhost" or similar > temporarily within the https:// URL. That same documentation section > also emphasizes removing that workaround once you are in production. > > AFAICT Apache CXF *is* shutting off that check[2] and supposedly > deferring it to MessageTrustDecider[3] (where it can be subsequently > attached in the cxf.xml file), but if the user does not implement a > MessageTrustDecider and manually check this value himself it will never > end up being made[4]. Even assuming a user is aware of this check being > disabled, most of them probably have never heard of the CXF-only > MessageTrustDecider, and so IMO it would be a bit too much to ask them > to create this object in order to reactivate that check. > > If I'm correct here, I think we should reinstate the CN check by > default, but provide users a cxf.xml client configuration setting that > disables that check if desired. I wouldn't have a problem with us using > "disabled by default" if that were the Java language default, but it > isn't, and so I think it should be reinstated for the benefit of newbies > as well as more advanced users who might not be aware that we disabled > this check to begin with. > > Thoughts? > > Regards, > Glen > > > [1] > https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Security__SSL__Workaround > [2] http://tinyurl.com/2el54h (line 155-177, 215) > [3] http://tinyurl.com/yt54uq > [4] http://tinyurl.com/2h3a4r (lines 637-645) > >
