users and groups.  It doesn't pass requests between child processes yet.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95918 13f79535-47bb-0310-9956-ffa450edef68

arbitrary code before the handlers are invoked.

This resolves an issue with incorrect 304s on If-Modified-Since mod_include
requests since ap_meets_conditions() is not aware that this is a dynamic
request and it is not possible to satisfy 304 for these requests (unless
xbithack full is on, of course).  When mod_include runs as a filter, it is
too late to set any flag since the handler is responsible for calling
ap_meets_conditions(), which it should do before generating any data.

If a module doesn't need to run such arbitrary code, it can just pass NULL
as the argument and all is well.

PR:	9673
Reviewed by:	Ryan Bloom and others


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95906 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95835 13f79535-47bb-0310-9956-ffa450edef68

  These emits occur mainline, outside of the pphrase_callback, so we never
  opened readtty or writetty.  But they are absolute failures, nothing the
  user could do to deal with them.  They are logged in the ssl vhost's error
  log.

  In this case, I forgot my SSLCertificateKeyFile, so the server never
  tried the callback.  writetty wasn't initialized, so we segfaulted.

  This segfault is due to misconfig, not to the dialog with the user.
  This is the easiest fix (easier to read, too), but we shouldn't need
  to worry too much that the release is tagged.  If we retag, fine, then
  grab it, but it only addresses a config problem.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95734 13f79535-47bb-0310-9956-ffa450edef68

Reported by:  Paul J. Reder
Submitted by: Ryan Bloom


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95604 13f79535-47bb-0310-9956-ffa450edef68

using the value of SSL_get_peer_certificate(ssl) to verify as it will
have been removed from the chain before it was put in the cache.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95603 13f79535-47bb-0310-9956-ffa450edef68

Obtained from:
Submitted by:
Reviewed by:
allow POST method over SSL when per-directory client cert
authentication is used with 'SSLOptions +OptRenegotiate' enabled
and a client cert was found in the ssl session cache.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95602 13f79535-47bb-0310-9956-ffa450edef68

Obtained from:
Submitted by:
Reviewed by:
'SSLOptions +OptRengotiate' will use client cert in from the ssl
session cache when there is no cert chain in the cache.  prior to
the fix this situation would result in a FORBIDDEN response and
error message "Cannot find peer certificate chain"


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95601 13f79535-47bb-0310-9956-ffa450edef68

to return an error rather than exiting directly


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95567 13f79535-47bb-0310-9956-ffa450edef68

questions about shmcb:

"Feel free to buzz me on shmcb matters to as/when you like - my time
 may be limited right now but I will certainly reply as best I can to
 anything that comes up."

Submitted by: Geoff Thorpe <geoff@geoffthorpe.net>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95550 13f79535-47bb-0310-9956-ffa450edef68

  cvs up/diff gets pretty hard to track with vc7 builds.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95524 13f79535-47bb-0310-9956-ffa450edef68

redirecting (.*) will allow an SSL protected page to be viewed
without SSL.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95501 13f79535-47bb-0310-9956-ffa450edef68

  The only remaining question ... are nested or strictly unnested locks
  expected by OpenSSL?  Right now I've left it as _DEFAULT for the platform
  preference.  Very simple code really - the server_rec was superfluous.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95497 13f79535-47bb-0310-9956-ffa450edef68

Not only should it just say "can't do that on win32," which is after all
the bottom line, it was spitting out openssl error messages which were
totally useless.  Eg:

[30/May/2002 17:31:17 05760] [error] Init: PassPhraseDialog BuiltIn not
supported in server private key from file
F:/Apache/Apache2/conf/ssl/secure.key (OpenSSL library error follows)
[30/May/2002 17:31:17 05760] [error] OpenSSL: error:0D084069:asn1
encoding routines:d2i_ASN1_SET:bad tag
[30/May/2002 17:31:17 05760] [error] OpenSSL: error:0D09D082:asn1
encoding routines:d2i_RSAPrivateKey:parsing
[30/May/2002 17:31:17 05760] [error] OpenSSL: error:0D09B00D:asn1
encoding routines:d2i_PrivateKey:ASN1 lib

Which is essentially saying "OpenSSL couldn't read your private key because
it was encrypted, and we can't get the passphrase the way you asked us to
on this platform."


Brought to my attention by the inquiry of:  Chris Hsiang <chsiang@ivivos.com>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95415 13f79535-47bb-0310-9956-ffa450edef68

  Based on DougM's feedback to the list...


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95408 13f79535-47bb-0310-9956-ffa450edef68

  Apparently Roy missed this comment.  Rephrase as a seperate paragraph
  to more clearly split credit for OpenSSL from credit for mod_ssl.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95407 13f79535-47bb-0310-9956-ffa450edef68

  Split out the LAYOUT


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95406 13f79535-47bb-0310-9956-ffa450edef68

  As we find the right places for this content, move them out in bits


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95405 13f79535-47bb-0310-9956-ffa450edef68

  All rather stale.  Any new/remaining issues should be moved to CHANGES
  in the present tense, as opposed to the "Future port to 2.0".  Heh


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95389 13f79535-47bb-0310-9956-ffa450edef68

threadsafe.

PR: 9469


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95327 13f79535-47bb-0310-9956-ffa450edef68

It's totally unsafe to use apr_pool_userdata_setn() in the post_config
phase of a module, since on some platforms when the DSO gets reloaded
between phases, the data segment will be at a different address on the
second phase and the userdata_get() call will fail.

PR: 9413
Submitted by: Tsuyoshi Sasamoto <nazonazo@super.win.ne.jp>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95287 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95189 13f79535-47bb-0310-9956-ffa450edef68

for example: <VirtualHost *:>, for which the core only spits out a warning:
 Name or service not known: Cannot resolve host name *: --- ignoring!


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95158 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95150 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95135 13f79535-47bb-0310-9956-ffa450edef68

standard ErrorLog directives.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95129 13f79535-47bb-0310-9956-ffa450edef68

The issue is that ssl_log doesn't handle apr_status_t result codes.  This
leads to a number of places (esp. with mutexes) where the error codes get
lost.  Rather than extending ssl_log further, since mod_ssl is part of
our core, migrate to ap_log_error.  This means that mod_ssl no longer
does its own logging.

Most uses of SSL_ADD_ERRNO are now mapped correctly to apr_status_t values
(mainly because the APIs that used to return errnos are now APRized and
have apr_status_t codes available).

SSL_LOG_TRACE and SSL_LOG_DEBUG were mapped to the APLOG_DEBUG values.
mod_ssl prints out a LOT of debugging information, so mod_ssl with LogLevel
Debug may not be a good idea - perhaps mod_ssl should be less chatty.

Numerous printf type collisions were also resolved.

(The ssl logging code itself will be removed in a subsequent commit.)

This has been discussed on dev@httpd, but the fact that there isn't
much to review besides the mindless changes, I'm going to commit now
and rely on CTR if I screwed up anything on the translation.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95127 13f79535-47bb-0310-9956-ffa450edef68

ssl_log_ssl_error() function that wraps ap_log_error instead.

This begins the migration from ssl_log() -> ap_log_error().  Divorcing
ourselves from the SSL_ADD_SSLERR option is required to make the next
pass easier.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95122 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95059 13f79535-47bb-0310-9956-ffa450edef68

get cross-process mutex permissions working.

This is waiting for a proper APR interface, but this does not mean that
we should remain broken in the meantime.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95057 13f79535-47bb-0310-9956-ffa450edef68

  Afraid these are likely generated, just something to watch out for
  in the future.  Address PR 8963


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95024 13f79535-47bb-0310-9956-ffa450edef68

This is admittedly rather ugly code to come up with a unique 4-byte
identifier for the thread.  Since our threads are pthreads and a pthread
maps 1:1 to a TCB, the address of the TCB is sufficient.   Yes, every
TCB sees a different piece of real storage mapped to the first page,
so the code does make sense.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95016 13f79535-47bb-0310-9956-ffa450edef68

Fix a case where an invalid pass phrase is entered and an
error message is given, but the prompt is not shown again.
This left the user in an ambiguous state.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94896 13f79535-47bb-0310-9956-ffa450edef68

to be unusable with mod_ssl.

PR: 8572


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94881 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94877 13f79535-47bb-0310-9956-ffa450edef68

for one thing.  But it just plain doesn't need it.  Rip it out to avoid
segfaulting.

Submitted by:  Aaron Bannert


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94876 13f79535-47bb-0310-9956-ffa450edef68

- Also a minor change to add more useful error
  logging for shmcb startup failures


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94875 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94696 13f79535-47bb-0310-9956-ffa450edef68

Submitted by: Thom May <thom@planetarytramp.net>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94631 13f79535-47bb-0310-9956-ffa450edef68

.y and .l files.  These must be kept newer than those at all times to avoid
introducing a dependency on flex and yacc.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@94623 13f79535-47bb-0310-9956-ffa450edef68