Apache: Cannot load .../modules/mod_ssl.so into server: (182)
Hi, On startup Apache says: Cannot load /apache/1.3.24/modules/mod_ssl.so into server: (182) I am running Apache as a service and get this error. Can anyone help please? Thanks, Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *** __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problems with engines in 0.9.8-beta1
On May 24 23:16, Geoff Thorpe wrote: On May 22, 2005 08:17 am, Corinna Vinschen wrote: now that I had first contact with engines, I thought it might be better to give them some testing. Yes, thanks for doing so :-) Sure. I just can't test if they *really* work since I'm obviously missing the stuff they're trying to connect to. However, I found that lib4758_cca.so and libncipher.so don't load, because the engine id differs from the engine name. The engine id of lib4758_cca.so is 4758cca instead of 4758_cca, the id of libncipher.so is chil instead of ncipher. Yes, this is unfortunate. I've just committed a fix to the 0.9.8-stable and HEAD branches that will tolerate both names when binding as a dynamic engine. It'd still be preferable to change the names of the generated shared libraries too so that the default name with static and dynamic use is the same (ie. using 'chil' for a built-in engine and 'ncipher' for an external engine make much sense). Right now the existing change will just allow you to dynamically bind using 'ncipher'. Please try out the next nightly snapshot if you're able. Works. But I agree, it be more correct to be able to load a chil and a 4758cca engine. Richard, any idea of how safe it would be to change the names of the two shared librariesy at this stage of the 0.9.8 betas? I'm reluctant to charge ahead for fear of breaking the strange builds (win32, VMS, cygwin, ...) WHAT? Cygwin a strange build? How dare you... ;-) Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Certificate verify failed on big-endian (Intel IXP425)
Hi, A few days ago I posted to openssl.users the message i attach below. I have done some more research and after seeing that the ssl code works on a little endian pc with 0.9.6, the problem is: - with the big-endian Intel IXP425 ARM running 0.9.6 - the code of the application (SER, voip proxy, with TLS). I have seen a few discussions about endiannes, about some test failing ... The next thing i would like to try is to cross-compile OpenSSL 0.9.7 for the IXP425 and install the new libraries. What is the safest way to avoid all conflicts, even big a big-performance penalty? Thanks! Cesc === Certificate verify failed ... incompatible versions 0.9.6m-engine and 0.9.7d? Hi, I am testing an application, which is a server and a client at the same time, connecting or receiving connections from the same application running on other machines. It all worked fine as long as: - All used v.0.9.7d - All of them were running on a i386 pc on debian linux (kernel 2.6.x). Now ... i managed to get the application to run on an ARM embedded system (intel ixp425, but different host byte order), which for now only has openssl version 0.9.6m installed. As said, it all would work fine ... till this ARM with openssl 0.9.6 came into play. Now, I cannot connect or accept connections from/to the ARM platform. If i do an ssl_connect (to a pc-based host), i get: * error: 14090086: SSL routines: SSL3_GET_SERVER_CERTIFICATE: certificate verify failed ... on the ARM-host If i do an ssl_accept (incoming connect from a pc-based host to the arm-host), i get: * error: 140890B2: SSL routines: SSL3_GET_SERVER_CERTIFICATE: no certificate returned ... on the ARM-host I have set VERIFY_PEER and VERIFY_PEER_ONCE, with no verification callback (pointer set to NULL). The certificates and configurations work (root CA is self-signed; server certificates, also used as client certs, are directly signed by root CA, and contain some private X509v3 extensions). On the ARM host i cannot do openssl verify ... i only have the libraries, not the binaries for the platform. Things i thought about: i am missing something which 0.9.7 does automatically and 0.9.6 doesn't; a question of byte-order on the hosts; the x509v3 private extensions; the self-signed root ca cert in 0.9.6; ... Any other ideas or solutions? Thanks in advance! Cesc.S __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate verify failed on big-endian (Intel IXP425)
On Wednesday 25 May 2005 09:11 am, Cesc wrote: I have done some more research and after seeing that the ssl code works on a little endian pc with 0.9.6, the problem is: - with the big-endian Intel IXP425 ARM running 0.9.6 - the code of the application (SER, voip proxy, with TLS). i posted some fixes a while ago for 0.9.7e which were accepted and are in 0.9.7g ... openssl configured all arm targets as little endian which is why it was failing -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to debug under Solaris-x86?
Buf if you issue disassemble command at debugger prompt, you should see that you're in _init and if you follow to failing address you're most likely to spot mov (%eax),%al, right? You are right: Dump of assembler code for function _init: 0xdfb1b7c0 _init+0: call 0xdfa6532c frame_dummy 0xdfb1b7c5 _init+5: add%al,(%eax) Of course, it is add rather than mov, because add instruction has zero opcode on intel. Right! I wrote mov off the top of my head, in reality I see add too. But one way or another it's Solaris x86 specific bug in GCC run-time environment. Mentioned linker deficiency is recognized in GCC source and workaroung was in place in elder GCC releases [at least it's present in my 2.95.x installation]. I guess it was erroneously omitted in some newer release. Try to patch your run-time environment by executing http://www.openssl.org/~appro/values.c and report back. The patch is designed to work with both old and new GCC releases. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
