Re: OpenSSL 3.0

You essentially have three choices: 1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire year without support or security patches. 2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue to receive patches on 1.0.2 for the remainder of the year. 3. Pay Saf

Re: Fingerprint mismatch only for 32-bit DLL linked statically to FIPS Capable OpenSSL

I ran into the same issue on my FIPS journey a few years ago. I'm assuming you are building for windows in which case setting the /FIXED flag is the right thing to do, however you cannot be guaranteed to get the address you specify - it may already be occupied in which case the dll will be re-based

FIPS 3.0 private_* hash functions

Hi all, I am in the process of making required changes to migrate our code to the 1.1.x branch. We are currently using the FIPS Object Module 2.0 and eagerly await word on the new 3.0 FIPS Object Module, but in the meantime there is one issue of concern in our code for which I need some clarificati

Cannot find access to CRL flags in 1.1.x

Migrating code base from 1.0.2 to 1.1.1c and have one last issue I cannot find a solution for: if (crl->flags & EXFLAG_CRITICAL) X509_CRL structure is opaque and I cannot access the flags member, however I cannot find any API call to retrieve the flags value. Thanks for any help/guidance, Paul

1.0.2 to 1.1 migration problem with verify_callback()

I am in the process of migrating our code from the 1.0.2 library to 1.1 and have run across a situation that I am struggling to reconcile: The existing code utilizes the verify_callback() function in order to perform validation measures against a peer certificate. This callback performs validation

[openssl-users] Static FIPS Library with Address Randomization

Platform: Win32 FIPS Object Module: 2.0.13 OpenSSL: 1.0.2j We've been using FIPS-capable OpenSSL for over a year now. Some of our components are .dlls that statically link the libraries. Using the BASE: linker flag (but not /FIXED) has worked well with only very occasional address clashes. The

[openssl-users] Guidance on proper usage of OpenSSL_add_all_digests

Using OpenSSL 1.0.1l I just learned the painful way that OpenSSL_add_all_digests() is not a thread-safe function. I had been calling this in the constructor of a class providing hash functions for multiple threads. My question is, how do I know if a thread instantiating my class has called OpenSSL

[openssl-users] RSA_generate_key fails in FIPS Mode with key size 2048

Using: FIPS Object Module 2.0.9 OpenSSL 1.0.1l When I call RSA_generate_key: if (rsa = RSA_generate_key(keySize, RSA_F4, NULL, NULL)) I get the following error string: (OPENSSL error:04081078:rsa routines:RSA_BUILTIN_KEYGEN:key size too small) As I understand, RSA Key size must be 2048 or greate

[openssl-users] OPENSSL error:21072077:PKCS7 routines:PKCS7_decrypt in FIPS mode

failedcert.crt Hello all, I've attached a .crt certificate file that we are experiencing a problem with. When trying to process this certificate using the PKCS7_decrypt( ) function. The error string is: OPENSSL error:21072077:PKCS7

Re: [openssl-users] Statically link FIPS OpenSSL to shared library application

Are you supplying a base address for the shared library when linking? I ran into this same problem but for Win32 .dll, but I'm not sure if there is the same requirement for Linux so's. The problem was without supplying a base address, the HMAC signature could not be found and the power on self test

Re: [openssl-users] FIPS Static Library linked into Win32 Dll builds but fails self test

Thank you...that would explain why I'm suddenly having success when I give our .dll a fixed address. Unfortunately, this is something we are trying to avoid. Even more unfortunate is we are stuck with Win32 (at least for another year) and linking to the executable is not a solution because the dll

[openssl-users] FIPS Static Library linked into Win32 Dll builds but fails self test

FIPS Object Module 2.0.9 OpenSSL 1.0.1l Platform: Win32 I am attempting to statically link a FIPS-capable library into a .dll. The .dll is built without errors and by viewing the .dll in a hex editor I can see the correct HMAC is embedded within and correct, but the self test is failing. Orig