tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
Date Tue, 18 Jun 2013 17:23:57 GMT
Hash: SHA256


On 6/18/13 12:58 PM, Steve Nickels wrote:
> Christopher Schultz wrote:
>>>> 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.
>> This could be a problem on *NIX as well -- any library may be
>> re-located by the loader for any reason.
> It's possible this could be a problem on *NIX, but it's my 
> understanding that this error is pretty specific to Windows. The 
> documentation for OpenSSL FIPS says that the 
> "Microsoft Windows specific error".

Interesting. I'll have to read a bit more about that.

>>> 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.
>> Or running within a JVM which has a significant amount of native
>> code that gets loaded first, which may cause the loader to
>> re-locate the library when it finally gets loaded.
>> Any interest in trying some Java-based testing using
>> libtcnative?
> I'm game, if you let me know what you'd like me to do. : )

All you should have to do is write a small Java program that calls
AprLifecycleListener.lifecycleEvent with an event of type

You'll of course have to call things like setFIPSMode(true), etc.

I wonder if you did that without the rest of Tomcat loaded if anything
would change. I would bet that it's more likely that the bulk of the
JVM is causing the re-location of the library than anything else.

Interesting thread:

Look at Andy Polyakov's comment from 18 Oct 2010 23:25 where he says:

In order for this to work it is implied that compiler
moves relocatable data from .rdata segment. Unix compiler actually do
that, but apparently not Windows :-(.

It also looks like OpenSSL has updated their build scripts for Visual
Studio, but it's possible that the FIPS version predates that patch.

>>> 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.
>> That would be good -- bug reports have more visibility than
>> mailing list posts, and it's a good place to collect information
>> all in one place.
> I submitted bug 55113 for this.
> (

I saw that, thanks.

>> I'm curious: what base address did you use when you changed it?
> The one that worked for me was 0x6FB00000.

Did you just choose one randomly?

I wonder if you follow the suggestions from the aforementioned thread
for re-building everything with the /FIXED switch. That seems to have
fixed everyone's issues, but you have to be sure to build everything
very carefully or one component can still be relocatable. tcnative of
course does not care.

>> That's a good point. Could you log that in Bugzilla as well?
>> There are (brief) building instructions on
>> but they should probably
>> also be in the BUILDING file.
> Submitted bug 55114 for this.
> (

Cool. It's likely to be fixed in a different way (by including both
*NIX and Windows building instructions instead of including only the
Windows build instructions) but at least you won't have to go to the
web site when you have a perfectly good file already downloaded.

>>> If there's a good place to put a wiki page about this, let me
>>> know, and I can try to add something.
>> Really anywhere under would be
>> great. If I were looking for information about this, I'm not sure
>> where I'd look first. Perhaps under "Security"?
> If I get a chance, I'll try and add something here.

Cool, thanks.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message