httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <>
Subject Re: [users@httpd] compiling openssl for openssl+apache+certs
Date Tue, 25 Feb 2003 23:55:06 GMT

* ( 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 :-) 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).

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

> = 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).

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

> 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

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


Geoff Thorpe

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message