Dr Henson:

I just built fips-1.2 under VS2010 (from a Visual Studio 2010 command prompt, 
under Windows Server 2008 [not 2008R2]).  Running out32dll\openssl.exe itself, 
with environment OPENSSL_FIPS=1, returns:

C:\openssl-fips-1.2\openssl-fips-1.2\out32dll>openssl
5324:error:2D06906E:FIPS routines:FIPS_CHECK_INCORE_FINGERPRINT:fingerprint 
does not match:.\fips\fips.c:238:

I'm running under Windows Server 2008, which uses the Vista codebase instead of 
the Windows 7 codebase.

If you would like me to send you any of my output files, I will, and if you 
would like me to do anything with the source, I will.  (This particular build 
was ms\do_ms.bat no-asm.)

-Kyle H

On Sun, Oct 17, 2010 at 5:04 AM, Dr. Stephen Henson <st...@openssl.org> wrote:
On Sat, Oct 16, 2010, Grant Averett wrote:


Hello, I've successfully built the validated FIPS object module and OpenSSL
0.9.8o on Windows with Visual Studio 2008 many times (both an x86 and x64
version) without issue and I can successfully build both with Visual Studio
2010.  However, the FIPS module built with Visual Studio 2010 fails the FIPS
test suite (out32dll\fips_test_suite.exe) and if I use the generated object
module to build FIPS validated OpenSSL DLLs, those DLLs also fail the self
test and can't be used to enable FIPS mode (OpenSSL reports "the fingerprint
does not match").


"out32dll\fips_test_suite.exe"  reports the following output when run right
after "ms\do_fips.bat": 1. Non-Approved cryptographic operation test...
a. Included algorithm (D-H)...successful2. Automatic power-up self
test...ERROR:2d06906e:lib=45,func=105,reason=110:file=.\fips\fips.c:line=238:FAILED!


The only difference between a working FIPS build and the failed build is the
Visual Studio environment. The working version is built using Visual Studio
2008 SP1 and the failed with 2010 (both using the Professional edition and
both on Windows 7).  I've done a little investigation and it appears the
2010 version of libeay32.dll is being relocated from the correct preferred
base address of 0xFB00000 to a different address. I have no idea why this is
happening and nothing I do seems to prevent the relocation.  I made sure to
turn off image randomization and even tried changing the base address of the
DLL during building using the command line option but it still gets
relocated when I try to use it.  If I use the Visual Studio 2008-generated
DLLs in place of the 2010 DLLs then they work fine and are not relocated.
It is very strange.  However, since the FIPS module itself fails the FIP
self-test I'm not sure this is significant.  If I use a static library
instead of the shared library OpenSSL DLL build the results are still the
same when I try to enable FIPS mode... "the fingerprint does not match".
I'm getting the "FIPS_R_FINGERPRINT_DOES_NOT_MATCH" error and not the
"FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED" error so I have a
feeling fixing the canister problem will fix the relocation issue with the
DLL.

I've tried everything I can think of and I'm running out of ideas.  Does
anyone have any suggestions on what could be the problem? Has anyone
successfully built and tested the FIPS canister with Visual Studio 2010?


I don't have access to Visual Studio 2010 so I can't reproduce this, I'm
wondering if some new feature in Windows 7 which VS 2010 makes use of is
interfering with the fingerprinting process.

What happens if you specify /FIXED when you build the DLL?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to