#### Questions on Building and Testing OpenSSL * Does OpenSSL use AES-NI or other speedups? The short answer is yes, unless you configure with "no-asm." What OpenSSL does is not obvious. The INSTALL document talks about the no-asm configuration option. Details about what the assembler code does in terms of optimization are only available by reading the source code comments in the various Perl files that generate the assembler, mostly. On x86, the assembly code uses the CPUID instruction (see the OPENSSL_ia32cap.pod manpage) to determine if various instructions (AES, SSE, MMX, etc) are available and will use them if so. For other processors, similar tests are performed if at all possible. * Why does Clang sanitizer give warnings? You need to build with -DPEDANTIC to run sanitized tests, otherwise you will get optimized assembler versions of some functions. * Why does the linker complain about undefined symbols? Maybe the compilation was interrupted, and make doesn't notice that something is missing. Run "make clean; make". If you used ./Configure instead of ./config, make sure that you selected the right target. File formats may differ slightly between OS versions (for example sparcv8/sparcv9, or a.out/elf). In case you get errors about the following symbols, use the config option "no-asm", as described in INSTALL: BF_cbc_encrypt, BF_decrypt, BF_encrypt, CAST_cbc_encrypt, CAST_decrypt, CAST_encrypt, RC4, RC5_32_cbc_encrypt, RC5_32_decrypt, RC5_32_encrypt, bn_add_words, bn_div_words, bn_mul_add_words, bn_mul_comba4, bn_mul_comba8, bn_mul_words, bn_sqr_comba4, bn_sqr_comba8, bn_sqr_words, bn_sub_words, des_decrypt3, des_ede3_cbc_encrypt, des_encrypt, des_encrypt2, des_encrypt3, des_ncbc_encrypt, md5_block_asm_host_order, sha1_block_asm_data_order If none of these helps, you may want to try using the current snapshot. If the problem persists, please submit a bug report. * Why does the OpenSSL compilation fail with "ar: command not found"? Getting this message is quite usual on Solaris 2, because Sun has hidden away 'ar' and other development commands in directories that aren't in $PATH by default. One of those directories is '/usr/ccs/bin'. The quickest way to fix this is to do the following (it assumes you use sh or any sh-compatible shell): PATH=${PATH}:/usr/ccs/bin; export PATH and then redo the compilation. What you should really do is make sure '/usr/ccs/bin' is permanently in your $PATH, for example through your '.profile' (again, assuming you use a sh-compatible shell). * Why does the OpenSSL compilation fail on Win32 with VC++? Sometimes, you may get reports from VC++ command line (cl) that it can't find standard include files like stdio.h and other weirdnesses. One possible cause is that the environment isn't correctly set up. To solve that problem for VC++ versions up to 6, one should run VCVARS32.BAT which is found in the 'bin' subdirectory of the VC++ installation directory (somewhere under 'Program Files'). For VC++ version 7 (and up?), which is also called VS.NET, the file is called VSVARS32.BAT instead. This needs to be done prior to running NMAKE, and the changes are only valid for the current DOS session. * What is special about OpenSSL on Redhat? Red Hat Linux (release 7.0 and later) include a preinstalled limited version of OpenSSL. Red Hat has chosen to disable support for IDEA, RC5 and MDC2 in this version. The same may apply to other Linux distributions. Users may therefore wish to install more or all of the features left out. To do this you MUST ensure that you do not overwrite the openssl that is in /usr/bin on your Red Hat machine. Several packages depend on this file, including sendmail and ssh. /usr/local/bin is a good alternative choice. The libraries that come with Red Hat 7.0 onwards have different names and so are not affected. (eg For Red Hat 7.2 they are /lib/libssl.so.0.9.6b and /lib/libcrypto.so.0.9.6b with symlinks /lib/libssl.so.2 and /lib/libcrypto.so.2 respectively). Please note that we have been advised by Red Hat attempting to recompile the openssl rpm with all the cryptography enabled will not work. All other packages depend on the original Red Hat supplied openssl package. It is also worth noting that due to the way Red Hat supplies its packages, updates to openssl on each distribution never change the package version, only the build number. For example, on Red Hat 7.1, the latest openssl package has version number 0.9.6 and build number 9 even though it contains all the relevant updates in packages up to and including 0.9.6b. A possible way around this is to persuade Red Hat to produce a non-US version of Red Hat Linux. * Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]? Failure in BN_sqr test is most likely caused by a failure to configure the toolkit for current platform or lack of support for the platform in question. Run './config -t' and './apps/openssl version -p'. Do these platform identifiers match? If they don't, then you most likely failed to run ./config and you're hereby advised to do so before filing a bug report. If ./config itself fails to run, then it's most likely problem with your local environment and you should turn to your system administrator (or similar). If identifiers match (and/or no alternative identifier is suggested by ./config script), then the platform is unsupported. There might or might not be a workaround. Most notably on SPARC64 platforms with GNU C compiler you should be able to produce a working build by running './config -m32'. I understand that -m32 might not be what you want/need, but the build should be operational. For further details turn to mailto:openssl-dev@openssl.org * Why does the OpenSSL test suite fail in sha512t on x86 CPU? If the test program in question fails withs SIGILL, Illegal Instruction exception, then you more than likely to run SSE2-capable CPU, such as Intel P4, under control of kernel which does not support SSE2 instruction extensions. See accompanying INSTALL file and OPENSSL_ia32cap(3) documentation page for further information. * Why does compiler fail to compile sha512.c? OpenSSL SHA-512 implementation depends on compiler support for 64-bit integer type. Few elder compilers [ULTRIX cc, SCO compiler to mention a couple] lack support for this and therefore are incapable of compiling the module in question. The recommendation is to disable SHA-512 by adding no-sha512 to ./config [or ./Configure] command line. Another possible alternative might be to switch to GCC. * Test suite still fails, what to do? Another common reason for test failures is bugs in the toolchain or run-time environment. Compiler bugs often appear in rather bizarre ways, they never make sense, and tend to emerge when you least expect them. One thing to try is to reduce the level of optimization (such as by editing the CFLAG variable line in the top-level Makefile), and then recompile and re-run the test. * I think I've found a bug, what should I do? If you are a new user then it is quite likely you haven't found a bug and something is happening you aren't familiar with. Check this FAQ, the associated documentation and the mailing lists for similar queries. If you are still unsure whether it is a bug or not submit a query to the openssl-users mailing list. If you think you have found a bug based on the output of static analysis tools then please manually check the issue is genuine. Such tools can produce a LOT of false positives. * I'm SURE I've found a bug, how do I report it? Please see https://www.openssl.org/community. * I've found a security issue, how do I report it? If you think your bug has security implications then please send it to openssl-security@openssl.org if you don't get a prompt reply at least acknowledging receipt then resend or mail it directly to one of the more active team members (e.g. Steve). If you wish to use PGP to send in a report please use one or more of the keys of the OMC listed at https://www.openssl.org/community/omc.html. Note that bugs only present in the openssl utility are not in general considered to be security issues. * How do I enable weak ciphers? Warning: known-insecure ciphers are disabled in newer releases of OpenSSL. There is good reason why these have been disabled by default. Consider upgrading to more robust options as these ciphers may only provide a facade of security. This option is not recommended for anyone other than maintainers of legacy applications. There are two parts to doing this. First, you must configure with "enable-weak-ssl-ciphers." This compiles the ciphers, but does not enable them at run-time; to do this you must set the "security level" flag. This can be done at build time to change the default, or it can be done at runtime to change it for particular SSL_CTX; see https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level.html for details. In other words, you should do one of the following: ./config enable-weak-ssl-ciphers -DOPENSSL_TLS_SECURITY_LEVEL=0 or # To configure and build ./config enable-weak-ssl-ciphers /* In your code */ SSL_CTX_set_security_level(ctx, 0);