On Nov 25, 2009, at 2:24 PM, John J. Consolati wrote:

> Here are the build commands I've tried:
> 
> ./configure --prefix=/home/consolati1/apache/httpd-2.2.14/installed 
> --enable-static-support --enable-ssl 
> --with-ssl=/home/consolati1/openssl/openssl-0.9.8l/installed 
> --with-mpm=prefork
> 
> ./configure --prefix=/home/consolati1/apache/httpd-2.2.14/installed/ 
> --enable-ssl --with-ssl=/home/consolati1/openssl/openssl-0.9.8g/installed/   
> (currently using this one)
> 
> Both of them result in the same thing, and were the commands my predecessor 
> used.

Should be fine.  

> I will try building it with the configure command you sent.  I haven't 
> personally tried gcc, but my coworkers have left extensive notes of errors 
> that gcc throws.  It couldn't hurt to try again.

Apache can be built with either gcc or Sun Workshop.  

> It is odd that libssl and libcrypt aren't in there -- I tried building 
> statically, as you can see, but the httpd -l that I posted was from the 
> second one (which should be dynamic).  Any ideas why they're missing?

The OpenSSL build system default to generating static archives, which are 
linked into the calling program and don't show up on ldd.  As others have 
pointed out, you can force OpenSSL to build shared libraries by passing the 
keyword 'shared' to ./config.   You might also check whether OpenSSL built with 
gcc or with Sun CC... it should not matter either way: a binary is a binary.  
The only thing a gcc binary does once built is require some gcc glue in order 
to run.  

Reviewing the output of Apache ./configure should give you an idea of which 
OpenSSL toolkit it finds.  The advantage of using static archives (.a libraries 
as opposed to .so) is that you are never in doubt of which OpenSSL toolkit is 
in use by httpd.  

Regarding SSLCACertificateFile: this directive is used to point to the CA 
Certificate used to challenge the client for a client-side certificate.  No 
luck involved here: it's simply a different purpose than 
SSLCertificateChainFile which points to the intermediary certificate chain 
presented by the server to allow the client to connect the server certificate 
to its root certificate database.  

Note: not having this chain in place is not the cause of your problem.  It will 
just fail the verification.  

Your build looks fundamentally sound.  Try connecting to your aberrant server 
with openssl s_client -connect aberrantserver:443 -debug and paste us the 
output.  It will give you more to work with than the browsers.

S.

> Thanks,
> John
> 
> On Nov 25, 2009, at 2:14 PM, dan_mit...@ymp.gov wrote:
> 
>> 
>> We are only at Apache 2.2.9, but don't have any problems.  The command I use 
>> to build apache with is:
>> 
>> ./configure --prefix=/usr/local/apache-2.2.9 --with-ssl=/usr/local/ssl 
>> --with-z=/usr/local/lib --enable-ssl --enable-cache --enable-disk-cache 
>> --enable-mem-cache --enable-autoindex --enable-mods-shared="rewrite ssl dav 
>> dav-fs proxy"
>> 
>> of course, this is building a shared mod_ssl.so, and a few other things.  We 
>> use gcc instead of Sun's.  Can you try it with gcc?  I can't image that is 
>> the problem, but it might be worth a test.
>> 
>> We have changed both Apache and OpenSSL versions, several times, and never 
>> had any certificate problems.
>> 
>> Here is one thing to look into...  Looking back at your 'ldd httpd' output, 
>> there is no mention of libssl or libcrypt, so I assume that you are 
>> statically linking them in.  Are you sure that you are picking up the 
>> OpenSSL version and not Sun's default installed version in /lib ?  Can you 
>> post your build command?  Personally, I like dynamic linking, so that you 
>> can upgrade to a new OpenSSL, without having to redo everything that uses it.
>> 
>> 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
>> 
>> Dan,
>> 
>> The error occurs on both Safari and Firefox on Apache 2.2.14.  We
>> don't have IE in our environment.  Both Safari and Firefox work as
>> they should with 2.0.47.
>> 
>> It looks like mod_ssl.c is compiled in -- it shows up with httpd -l.
>> 
>> I've checked the links you sent me.  The description doesn't provide a
>> whole lot of detail, and, according to the other one, I checked to
>> make sure I am using prefork instead of MPM -- it seems to default to
>> prefork anyway, but I specified it in the /config before compilation.
>> 
>> I've Googled to my wit's end for several days without finding anything
>> conclusive.  Some pages hint at compilation options, others at
>> compilers (I'm using Sun's cc, not gcc), but nothing conclusive.
>> 
>> Here is one question I couldn't find the answer to, though: if I
>> requested a server certificate using a specific version of OpenSSL,
>> can I use that same certificate in a different version of Apache with
>> a different version of OpenSSL?  Or do I have to re-request if I
>> upgrade OpenSSL?  A long shot I know, but I'm running out of options...
>> 
>> Thank you for the help,
>> John
>> 
>> On Nov 25, 2009, at 12:07 PM, dan_mit...@ymp.gov wrote:
>> 
>> >
>> > 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
>> >
>> >
>> >
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
>> 
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> 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



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to