John,
You should not need to upgrade Solaris. I've got apache running on a
solaris 9 box just fine.
Your "wrong path" shouldn't be a problem either. Those are just "the last
place to look" for an .so. Solaris will use what is in the 'crle' command
and the LD_LIBRARY_PATH environment variable first (I'm not sure of the
order).
You may or may not have a mod_ssl.so, depending on how you compiled
apache. If you run:
httpd -l (that's an el)
It will list out which modules are compiled in. If you see mod_ssl.c, you
will not have a mod_ssl.so. Otherwise, mod_ssl.so should normally be in
your apache's modules subdirectory.
Do you only get the error on Firefox and not IE?
Dan
Please respond to users@httpd.apache.org
To: users@httpd.apache.org
cc: (bcc: Dan Mitton/YD/RWDOE)
Subject: Re: [us...@httpd] SSL on Apache 2.2.14
LSN: Not Relevant
User Filed as: Not a Record
Here is the complete command:
openssl s_server -cert /erd/www/erd/server/apache/httpd-2.2.14/
installed/conf/ssl.crt/www-erdc.crt -key /erd/www/erd/server/apache/
httpd-2.2.14/installed/conf/ssl.key/www-erdc.secureprivate.key -
CAfile /erd/www/erd/server/apache/httpd-2.2.14/installed/conf/ssl.crt/
intermediate.crt -www
Your suggested 'GET / HTTP/1.0\r\r' was successful.
However, I found something interesting doing an ldd -- a few of them
have wrong paths:
bash-2.05# ldd httpd
libm.so.1 => /usr/lib/libm.so.1
libaprutil-1.so.0 => /wrong/path
libexpat.so.0 => /wrong/path
libapr-1.so.0 => /wrong/path
libuuid.so.1 => /usr/lib/libuuid.so.1
libsendfile.so.1 => /usr/lib/libsendfile.so.1
librt.so.1 => /usr/lib/librt.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libc.so.1 => /usr/lib/libc.so.1
libucb.so.1 => (file not found)
libresolv.so.2 => /usr/lib/libresolv.so.2
libelf.so.1 => /usr/lib/libelf.so.1
libucb.so.1 => /usr/ucblib/libucb.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmd5.so.1 => /usr/lib/libmd5.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1
/usr/platform/SUNW,Sun-Fire-V250/lib/libmd5_psr.so.1
I wasn't sure where to find mod_ssl.so -- I could only find mod_ssl.h.
Is there a way to change the links without rebuilding?
Thank you,
John
On Nov 25, 2009, at 11:21 AM, Sander Temme wrote:
>
> On Nov 25, 2009, at 10:17 AM, John J. Consolati wrote:
>
>> Thank you for the reply.
>>
>> Unfortunately, upgrading Solaris isn't an option. Here is the
>> version I have to work with (quite old..):
>>
>> bash-2.05# cat /etc/release
>> Solaris 9 4/04 s9s_u6wos_08a SPARC
>> Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
>> Use is subject to license terms.
>> Assembled 22 March 2004
>> bash-2.05# uname -a
>> SunOS lucky 5.9 Generic_118558-17 sun4u sparc SUNW,Sun-Fire-V250
>>
>> I've been using the Sun cc, not gcc, to compile everything.
>>
>>
>> Here is the output from the openSSL commands:
>>
>> openssl -certs....etc etc
>
> What is your complete command line here?
>
>> Using default temp DH parameters
>> Using default temp ECDH parameters
>> ACCEPT
>> -----BEGIN SSL SESSION PARAMETERS-----
>> MHUCAQECAgMBBAIAOQQgXdTo4sJayMnyXJOOV7YI1JLumr7lqj4Sj+kZZTIeX2wE
>> MO2ne8Ry2DUppChW6xz01mi4gMU+WsyaH6SPREMHpFcSCBYmpX5sD+VVBS3F/Ajy
>> V6EGAgRLDXPAogQCAgEspAYEBAAAAAE=
>> -----END SSL SESSION PARAMETERS-----
>> Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-
>> RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-
>> SHA:DHE-DSS-AES128-SHA:AES128-SHA:IDEA-CBC-SHA:RC4-SHA:RC4-MD5:EDH-
>> RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-
>> SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-
>> MD5
>> CIPHER is DHE-RSA-AES256-SHA
>>
>>
>>
>> And on the other terminal:
>>
>> bash-2.05$ openssl s_client -connect localhost:4433
>> CONNECTED(00000003)
>> depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms
>> of use at https://*www.*verisign.com/rpa (c)05/CN=VeriSign Class 3
>> Secure Server CA
>> verify error:num=20:unable to get local issuer certificate
>> verify return:0
>
> That's not a problem, just OpenSSL complaining it can't find the
> Verisign root cert. If you happen to have a copy of that (like your
> browser does) and point openssl s_client to it, it can verify all
> the way to the top. This does not impact the connection itself.
>
>> ---
>> Certificate chain
>> 0 s:/C=US/ST=California/L=Livermore/O=Lawrence Livermore National
>> Laboratory/OU=Environmental Restoration Division erdc/CN=www-
>> erdc.llnl.gov
>> i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
>> at https://*www.*verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure
>> Server CA
>> 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of
>> use at https://*www.*verisign.com/rpa (c)05/CN=VeriSign Class 3
>> Secure Server CA
>> i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
>> Authority
>> ---
>> Server certificate
>> -----BEGIN CERTIFICATE-----
>> certificate hash...
>> -----END CERTIFICATE-----
>> subject=/C=US/ST=California/L=Livermore/O=Lawrence Livermore
>> National Laboratory/OU=Environmental Restoration Division erdc/
>> CN=www-erdc.llnl.gov
>> issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of
>> use at https://*www.*verisign.com/rpa (c)05/CN=VeriSign Class 3
>> Secure Server CA
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 2973 bytes and written 258 bytes
>> ---
>> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
>> Server public key is 1024 bit
>> Compression: NONE
>> Expansion: NONE
>> SSL-Session:
>> Protocol : TLSv1
>> Cipher : DHE-RSA-AES256-SHA
>> Session-ID:
>> 5DD4E8E2C25AC8C9F25C938E57B608D492EE9ABEE5AA3E128FE91965321E5F6C
>> Session-ID-ctx:
>> Master-Key:
>>
EDA77BC472D83529A42856EB1CF4D668B880C53E5ACC9A1FA48F444307A45712081626A57E6C0FE555052DC5FC08F257
>> Key-Arg : None
>> Start Time: 1259172800
>> Timeout : 300 (sec)
>> Verify return code: 20 (unable to get local issuer certificate)
>> ---
>>
>> Looks like there is a problem with one of the certificates, but I'm
>> not sure how to proceed...
>
> At this point, you have a valid handshake, and the client and server
> have exchanged data encrypted and MACed with the session keys. All
> is well. You could type on the command line 'GET / HTTP/1.0\r
> \r' (two returns) and you'll get the status page generated by
> openssl s_server -www.*
>
> This means you have a configuration problem with Apache. Make sure
> you're using the ssl and crypto libraries that you think you are by
> running ldd on the httpd binary and the mod_ssl.so binary. While
> the Solaris build environment usually gets this right by hardcoding
> the path to the libraries at link time, make sure this is ok at run
> time.
>
> Then, make sure your server is configured correctly, and that your
> SSL virtual host(s) use the correct combination of
> SSLCertificateFile and SSLCertificateKeyFile.
>
> S.
>
>> Again, thank you for your help, I appreciate it.
>>
>> Regards,
>> John
>>
>>
>> On Nov 25, 2009, at 10:00 AM, daniel.goul...@and.co.uk wrote:
>>
>>> This sounds like a Solaris bug.
>>>
>>> Make sure you have a recent version of Solaris or the latest patches
>>> installed...
>>>
>>> What release/patch level are you using?
>>>
>>> Danny
>>>
>>> ________________________________
>>>
>>> From: "John J. Consolati" <consola...@llnl.gov> [mailto:"John J.
>>> Consolati" <consola...@llnl.gov>]
>>> Sent: 25 November 2009 17:23
>>> To: users@httpd.apache.org
>>> Subject: [us...@httpd] SSL on Apache 2.2.14
>>>
>>>
>>> Hello,
>>>
>>> Hopefully someone will be able to help, as I've been working on this
>>> problem for quite a while and have hit a wall. I'm trying to upgrade
>>> Apache 2.0.47 to 2.2.14, and I need SSL support. Everything seems to
>>> build and compile okay, but when I try to access my site running on
>>> 2.2.14, I get a strange error from Firefox: "Secure connection
>>> failed. An error occurred during a connection to xxxxxx. SSL peer
>>> reports incorrect Message Authentication Code. (Error code:
>>> ssl_error_bad_mac_alert)."
>>>
>>> I've tried compiling with OpenSSL 0.9.8L and 0.9.8G with the same
>>> results. This is hosted on a Solaris sparc box. The 2.2.14 server is
>>> utilizing all the same files and SSL certificates as the 2.0.47
>>> server. I've called Verisign; I have valid certificates, but they've
>>> never heard of this error before. If I self-sign a certificate and
>>> test it with the 2.2.14 server, it seems to work (except for the
>>> expected error message regarding self-signed certificates).
>>>
>>> Searching on Google has led me to try forcing Apache to compile with
>>> prefork enabled (but it seems to default to that anyway on Solaris).
>>> I've also tried statically linking Apache during compile with the
>>> same
>>> results.
>>>
>>> If anyone has any ideas or suggestions, I'd very much appreciate
>>> them...
>>> Thank you,
>>> John
>>>
>>> ---------------------------------------------------------------------
>>> The official User-To-User support forum of the Apache HTTP Server
>>> Project.
>>> See < URL:http://**httpd.apache.org/userslist.html> for more info.
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> " from the digest: users-digest-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security
>>> System.
>>> For more information please visit http://**www.**messagelabs.com/
>>> email
>>> ______________________________________________________________________
>>>
>>>
>>> ______________________________________________________________________
>>> This e-mail and any attached files are intended for the named
>>> addressee only. It contains information, which may be confidential
>>> and legally privileged and also protected by copyright. Unless you
>>> are the named addressee (or authorised to receive for the
>>> addressee) you may not copy or use it, or disclose it to anyone
>>> else. If you received it in error please notify the sender
>>> immediately and then delete it from your system. Please be advised
>>> that the views and opinions expressed in this e-mail may not
>>> reflect the views and opinions of Associated Newspapers Limited or
>>> any of its subsidiary companies. We make every effort to keep our
>>> network free from viruses. However, you do need to check this e-
>>> mail and any attachments to it for viruses as we can take no
>>> responsibility for any computer virus which may be transferred by
>>> way of this e-mail. Use of this or any other e-mail facility
>>> signifies consent to any interception we might lawfully carry out
>>> to prevent abuse of these faciliti
>>> es.
>>> Associated Newspapers Ltd. Registered Office: Northcliffe House, 2
>>> Derry St, Kensington, London, W8 5TT. Registered No 84121 England.
>>
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server
>> Project.
>> See <URL:http://*httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> " from the digest: users-digest-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>>
>
>
>
> --
> Sander Temme
> scte...@apache.org
> PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
>
>
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
