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 Mon, 03 Mar 2003 19:46:10 GMT

Geoff and others,

Thanks for all your help and suggestions.  You made a lot of good 
points.  A couple days ago I finally got openssl, mod_ssl, and the rest 
all working with apache.  At some point I hope to go back into my 
notes to see how I did it.  :)  Now I just need to drill into the 
httpd.conf.  So there's some reading and testing ahead.  Hopefully not, 
but probably I'll be back in a couple days.


Regards,
ken

PS. Haven't seen your announcement.

At 18:06 (UTC-0500) on Wed, 26 Feb 2003 Geoff Thorpe said:

= Hi,
= 
= * gebser@ameritech.net (gebser@ameritech.net) wrote:
= > 
= > At 18:55 (UTC-0500) on Tue, 25 Feb 2003 Geoff Thorpe said:
= 
= [snip]
= 
= > 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.
= 
= OpenSSL's config/Configure defaults are pretty normal, because
= /usr/local/{bin,lib,man,...} is usually for "do-it-yourself" system-wide
= builds/installs, whereas /usr/{bin,lib,...} is for stuff bundled with
= the operating system and/or installed by the package-management system
= (if there is a difference). I think OpenSSL's build system may be a
= little odd internally, but externally it presents a reasonable
= approximation to normality for this sort of thing. You could always
= provide "--prefix=/usr" if you want to, but that would (almost
= certainly) start killing off pieces of RPM-installed software and would
= give you every chance of utterly plooking your system. I assure you
= plook is a word, really. BTW: Any "standard" autoconfy software would
= probably default to /usr/local/ as an installation prefix too, and
= though openssl isn't "standard" or "autoconfy", it certainly tries to do
= the sensible thing.
= 
= > 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.
= 
= On linux it is unlikely to make a shred of difference, but on weirder
= systems (HPUX is a likely candidate), the building of libraries and
= executables may require certain path information to be wired into the
= binaries. As such "./config --prefix=/opt" should produce libraries and
= binaries that expect, *at run-time*, to find each other installed in
= /opt/{bin,lib,...}. On the other hand, if you are wanting to produce an
= installable tarball, RPM, DEB, [whatever...] you won't want to actually
= to copy the compiled/linked binaries into /opt, but instead put them
= somewhere temporary for packaging. Eg. "make install
= --prefix=/tmp/packaging/foo", so you get a fake installation tree in
= /tmp/packaging/foo that you can then zip/gz and distribute as a package.
= The point is that the binaries aren't built to be *used* in
= /tmp/packaging/foo, they are built to be used in /opt. That's the
= difference, more or less, with a good deal of vague handwaving on my
= part. I suggest you avoid using --prefix in "make install" and put your
= installation directory in "./config --prefix=..." and then forget about
= it (it'll be placed in the top-level Makefile produced by the
= configuration, if you need to remember what you'd specified).
= 
= > 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.
= 
= It shouldn't be that dicey - there's no reason at all you can't build
= your own openssl tree and build other applications around it. The risk
= is that other software may not have correct configuration code, and so
= whilst you may think you're going to be using the headers and libraries
= of your own install, there's the chance it may pick up the system-wide
= version installed from RPM. I think this is a potential problem with
= Apache's configuration. One of the problems is that providing
= --with-ssl=../openssl (for example) to Apache's "configure" is not
= converted to an absolute path with the normal "the_real_path=`cd
= the_relative_path ; pwd`" trickery. When you consider that the only code
= that cares about openssl is sitting two directories deep in
= modules/ssl/, the relative path that makes sense to the top-level
= configure script is not going to be any use from where it's needed.
= There are other weirdnesses in there that need fixing BTW, I'm looking
= into it (just finished some distcache/apache autoconf tomfoolery so I
= should now be able to take a poke at Apache's built-in stuff).
= 
= > = 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.  
= 
= It also makes sense to consider the Redhat-produced RPM route for this
= sort of thing anyway - as long as it does what you want it to do, it's
= much easier to be guided by the system than to fight tooth and nail
= against it. Eg. if you end up needing more sophisticated certificate
= management stuff, perhaps something like OpenCA or some other wrapper
= around the openssl tools, then going the RPM route will ensure that
= everything is kept hooked up with everything else w.r.t. versions,
= paths, etc. For linking into Apache itself, I still think however you're
= better to build your own temporary 0.9.7-based tree and *static* link
= that in. But what you decide to do with the certificate/key files [etc],
= and which tools and versions you use at the time, shouldn't matter a jot
= - so go with what's easiest.
= 
= > = 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.
= 
= Even more reason to build your own openssl code for linking into apache
= then. Otherwise you'll be dependent on redhat whenever you feel you want
= (or need) to upgrade :-) BTW: the fix is not anything mission-critical, and
= would be more important in something like Apache itself than the openssl
= utilities (which are not really used for SSL/TLS serving). The
= exceptions are any other SSL/TLS-dependant apps you use that are from
= Redhat's own RPMs, eg. stunnel perhaps?
= 
= > = 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
= 
= Not at all, but not nearly as much as I wouldn't mind contributions to
= the project. Documentation help, anyone? :-)
= 
= > = 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.  :}
= 
= Oh it certainly is cruel, but usually in unforeseen ways. ;-)
= 
= Cheers,
= Geoff
= 
= 


---------------------------------------------------------------------
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