> > I figured out the problem. The error was due to my system rebasing the > > libeay32.dll library from its desired base address of 0xFB00000. > > According to OpenSSL documents, this is supposed to generate a > > specific error message of > > FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED, but > because I wasn't > > seeing that, I didn't think that was the problem. > > Interesting. Do you think it was being swallowed-up somewhere? Like I said, > tcnative/FIPS hasn't gotten a huge amount of exposure.
I think the error message issue might be a problem with OpenSSL itself. As far as I can tell, tcnative is simply parroting back the error message that OpenSSL gives it. > Do you think there are ways it could be improved? Better error checking, > etc.? I implemented it as simply as I possibly could. The biggest problem seems to be that something in Tomcat on Windows is interfering with OpenSSL's normal base address request (0xFB00000). Normally this doesn't matter, but with the FIPS build, if the base address of the library is moved from what it expects, the result is a fingerprint error when FIPS mode is enabled. I ran the openssl utility on the same system as Tomcat, and Process Explorer shows that its copy of libeay32.dll stays at the correct address. Additionally, I tested the FIPS-compatible libeay32.dll on a different server with Tomcat, and had the same problem. This seems to indicate that the memory address issue is specific to Tomcat, not the server. I can't tell from Process Explorer why libeay32.dll is being rebased (I didn't see any other libraries under tomcat7.exe that were obviously taking up the same address space). I think it's going to take someone with more experience with both Windows and Tomcat than I to figure that one out. I suppose it might be worthy of a bug report, at least. > (I also noticed a small bug when checking the code around FIPS_mode_set in > tcnative: the OpenSSL docs say that if > FIPS_mode_set(x) is successful and x != 0, then the function returns x. The > check in there is against 1 and not x. So that could afford to be fixed.) > > > However, process explorer showed that the base address of libeay32.dll > > in the tomcat7.exe process was not at its correct base address. I > > recompiled OpenSSL with a new base address, verified that the new dll > > wasn't being rebased, and then turned on FIPS mode, and it worked. > > Wow, that could certainly confuse things. > > Again, I don't know anything about building on win32, but is that the kind of > thing that we could better-document (or document /at all/) somewhere in > the source bundle? Is there a project file that could contain such a hint > that a > casual DIY user like you would have consulted? If the fix for the memory rebasing issue ends up being that OpenSSL needs to be configured with a different base address, that would be good to include in the build documentation for tcnative. The file \jni\native\srclib\BUILDING would be a good place for such a note. But, if the interfering Tomcat piece were to be found and resolved, you wouldn't need it. > > With my test application, the original base address was not being > > changed by the OS, according to process explorer, which is why it > > worked with the original build. > > > > Thanks for your help! > > No problem. If there were any other gotchas you found when building > tcnative/FIPS/win32 could you let us know? Actually, creating a Wiki page is > easy to do and you could help others who are trying to do the same thing. One minor issue I found when building tcnative on Windows was that the BUILDING file in the \jni\native directory in tomcat-native-1.1.27-win32-src.zip appears to contain UNIX build instructions. This probably isn't appropriate, since the zip file is specific to win32. If there's a good place to put a wiki page about this, let me know, and I can try to add something. --Steve Nickels Ipswitch, Inc.
