httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From geb...@ameritech.net
Subject Re: [users@httpd] compiling openssl for openssl+apache+certs
Date Wed, 26 Feb 2003 19:40:04 GMT

At 18:55 (UTC-0500) on Tue, 25 Feb 2003 Geoff Thorpe said:

= Hi,
= 
= * gebser@ameritech.net (gebser@ameritech.net) wrote:
= > 
= > At 23:37 (UTC-0500) on Mon, 24 Feb 2003 Geoff Thorpe said:
= > 
= > = More or less, it's the traditional sort of "--prefix=<path>" thing;
= > = you'll get executables in <path>/bin, headers in <path>/include, etc.
= > 
= > Yeah.  That much I got from the INSTALL file that came with openssl.  
= > To further muddy the waters, there's also a "--prefix" option to "make
= > install".  If "./config --prefix=xxx" puts executables in/under xxx,
= > then what does "make install --prefix=xxx" do?  If I specify a path when 
= > running "./config ...", do I also need to specify the same path when 
= > doing "make install"?  Or will the second know about the first?
= 
= I don't tend to mess with the build system myself, certainly not with
= respect to the handling of weird cases like that. Short of trying those
= things myself, I couldn't tell you off-hand - so I guess you should try
= if you want to see :-) 

Very true.  I've had to do this sort of testing before but was hoping to
avoid spending a few days doing that sort of thing again.  It's a little
dismaying that the documentation is so poor that this is necessary.  
But I guess this is one of the trade-offs when using free source.  :-/


= However I expect the ability to do "./config
= --prefix=..." and then "make install --prefix=<something-else>" may
= perhaps be to support package-builders, where the directory for packages
= to eventually be installed to isn't necessarily where you want to "make
= install" to copy the files to in the mean time. I doubt any of this
= really matters as far as you're concerned when building apache (just use
= "./config --prefix=...") - what you need to make sure of is that you
= build your own version of OpenSSL X (for some suitable value of 'X') and
= that Apache does not use the headers nor libraries of OpenSSL Y, where
= 'Y' is whatever Redhat/whoever bundle with your system. This is the
= part I'm not sure about in the Apache configuration scheme (--with-ssl
= for one thing does not seem to do anything sensible with relative paths
= - I'm working on fixing a few things with that autoconf code).

Yeah, this is another aspect of the same problem: when doing the apache
compile, apache (seemingly) needs to know where to find (some particular
part of?) ssl.  It's been a week now since I read the docs on compiling
apache, and I deleted the whole install tree (a couple times already),
so I don't have it available right now, so I can't say right now if the
docs for INSTALLing apache say where (the various parts of) openssl
should be; but I don't think so.  Otherwise I wouldn't be here asking 
about it.  Furthermore, there's other apps which use ssl and would 
expect to find it in a specific location-- e.g., ldap.  So putting ssl 
in the wrong place-- and /usr/local surely isn't the right place, at 
least not on my distro-- would break all of those apps.

The openssl docs confirm what you say: "make install --prefix=XXX" can 
be used by packagers.  But it also means that it does control where the 
files will be installed.  Because it is an option, there must be a 
default.  Is this default affected by the "--prefix" option to "config"?  
I guess there's no answers to this question other than, as you say, just 
trying it.

You're right again about the complications which may result from 
conflicts with redhat.  It's always a dicey situation when you add a 
non-rpm package to a redhat system, especially so when other 
mission-critical apps depend on that package.  I'm looking at my rpm 
database getting trashed even if the install of openssl, apache, and the 
others goes perfectly.  Hmmm....  Maybe I should rethink this whole 
avenue.


= 
= > = Depends - if you will generate your certificates+keys (and what-not)
= > = straight away and then won't need to meddle with things at run-time, you
= > = might be best to generate those certificates/keys/... and then not worry
= > = about openssl at all from that point on. 
= > 
= > Generating certificates and keys hasn't been a problem.  I've already 
= > done that with openssl v.0.9.6d.  But of course I don't want to use that 
= > version.  I can still use those same certificates and keys when (if) I 
= > get openssl v.0.9.7 compiled, yes?
= 
= Yep, those PEM file formats are very stable because too much would
= crumble if compatibility got broken :-) BTW: For this reason, the
= openssl tools installed in your system (RPM, DEB, ...) could be used to
= parse, create, modify, revoke, [etc] your certs and keys - there is no
= requirement for it to be the same version or installation of openssl as
= Apache is linked with.

Cool!  Thanks for that.  The logic of the whole certificate thing would 
seem to indicate that, but you never know.  


= 
= > = The only issue then will be
= > = whether you go with static or dynamic linking - as an openssl developer
= > = I can tell you that the official line there is that no binary
= > = compatibility is guaranteed or even likely between releases (for now at
= > = least) and that use of shared-libraries is very much a caveat emptor.
= > = That said, Redhat does it so it must be right, right? :-)
= > 
= > I haven't found anything suggesting that Redhat offers an openssl above 
= > v.0.9.6d for its 7.2 release.  If someone has information to the 
= > contrary, please let me know.
= 
= It certainly should be providing something newer, because a security-fix
= release was put out last week to cover timing-attack vulnerabilities in
= the SSL/TLS implementation. Check the updates - it'd probably be 0.9.6i
= unless Redhat have ransacked the versioning (or backfitted the patch to
= 0.9.6d and called it something altogether odder).

I've checked a number of redhat (and mirror) sites as late as yesterday
and haven't found an openssl version above 0.9.6d or even with a
timestamp later than fall of last year.  I can't imagine that redhat 
hasn't put out an rpm with a fix, but if they have, they're not making 
it very apparent.  I'd welcome correction on this from anyone.


= 
= > Another possibility is that the Stronghold server may run on 7.2.  Has 
= > anyone done that?
= 
= I used to work on Stronghold in a former life, but I can't speak for
= recent versions. Joe Orton is probably lurking on this list - Joe, do
= you have any comment?
= 
= > Welcome to the group.
= 
= Cheers :-) I am working on distcache integration for Apache 2 (and
= Apache 1.3/mod_ssl 2.8.12). I should probably send an ANNOUNCE at some
= point about that. (www.distcache.org)

Lookin' good.  I'll definitely read your announce when it comes out.  
Hope you won't mind questions on it.  :^0


= 
= > Yeah, static binaries aren't the way to go-- not for a webserver anyway.  
= > Well, for narrow purposes maybe.  Most of the time there's always 
= > another Next Great Thing you want to do on the site and this requires 
= > some new module.  I couldn't see recompiling the whole webserver every 
= > time you wanted to add some additional functionality.
= 
= Generally speaking, I agree. Using shared libraries to reduce footprint
= of an application suite makes sense, because the shared-library can be
= kept (more or less) up-to-date with its associated components and
= dependencies shouldn't be a hassle. Trying to handle shared-libraries as
= system-wide "services" to arbitrary external applications is more
= problematic. Horses for courses, and all that. However in this case, the
= issue is more about package management problems than anything
= philosophical - Redhat ship a highly-patched openssl using the 0.9.6
= branch rather than the newer 0.9.7 branch. With the huge number of
= dependencies on that package, and what appears to be an inability to
= support multiple versions installed in parallel (I welcome correction on
= this if I'm wrong), you are thus tied to whatever their current package
= version is. Likewise, so are all the other applications built around
= openssl. So I think you're best off having your own up-to-date (and
= unmodified) openssl source tree and build an apache that is statically
= linked against that. If you try dynamic linking, you open a can of worms
= w.r.t. clashes between the versions installed in /usr/lib/ and your own
= build.

Yet another complication... and one which goes a way to killing the 
software eclecticism which is foundational to UNIX (if not software 
overall).


= 
= > = What will you need to be able to do, w.r.t. crypto maintenance, from
= > = your Apache installation once you're set up?
= > 
= > It's for a little e-commerce site.  No credit cards.  I want to let 
= > certain people log in from the world to upload files.  So there'll need 
= > to be certificates and passwords.  What do you mean by "crypto 
= > maintenance"?
= 
= I mean manipulating certs, keys, CRLs, or anything like that. However as
= I mentioned earlier (and hadn't twigged to in my first post), the
= version of the "openssl" utility (and any supporting script wrappers)
= installed by redhat would probably be just fine for manipulating these
= things later if you need to.

That's good to hear. I'd hope I wouldn't need to renew certs, do new
passwords, etc. whenever I upgraded ssl.  Maybe it's not such a cruel 
world after all.  :}


= 
= Cheers,
= Geoff

And back at ya,
ken



---------------------------------------------------------------------
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-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message