Virtual Secured Host (Help!).
Dear sir, I am trying to set two named base Secured Virtual Hosts under one httpd daemon as follows: NameVirtualHost 207.99.47.2:443 ServerName www.cartco.com DocumentRoot /WebSites/cartco.com/docs SSLEnable SSLRequireSSL SSLCertificateFile real-estate.crt SSLCertificateKeyFile real-estate.key.unsecure ... NameVirtualHost 207.99.47.2:443 ServerName secure.real-estate.org DocumentRoot /WebSites/real-estate.org/docs SSLEnable SSLRequireSSL SSLCertificateFile cartco.crt SSLCertificateKeyFile cartco.key.unsecure ... When I start apache everything seems ok. However when I'm trying to access the second domain (ie https:secure.real-estate.org) I get a certificate file from cartco (ie cartco.crt). This in turn is causing the IE 4.0 browser not be able to proceed. Because the domain name doesn't match the name on the certificate. I appears as if the VirtualHost for secure.real-estate.org is not been read. Am I doing anything wrong, or is there a bug that I not aware of? Thanks so much ahead. Yossi __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Virtual Secured Host (Help!).
On Tue, Nov 10, 1998, Cohen, Joseph wrote: > I am trying to set two named base Secured Virtual Hosts under one httpd > daemon as follows: > > NameVirtualHost 207.99.47.2:443 > >[...] > > > NameVirtualHost 207.99.47.2:443 > >[...] > > > > When I start apache everything seems ok. However when I'm trying to access > the second domain (ie https:secure.real-estate.org) I get a certificate file > from cartco (ie cartco.crt). This in turn is causing the IE 4.0 browser not > be able to proceed. Because the domain name doesn't match the name on the > certificate. > > I appears as if the VirtualHost for secure.real-estate.org is not been read. > > Am I doing anything wrong, or is there a bug that I not aware of? This is not a bug in mod_ssl or Apache itself. It's a basic problem with HTTP over SSL (=HTTPS). You can't use (or under certain circumstances at least only use one) name-based virtual hosts in conjunction with SSL. You have to use IP-based virtual hosts. Please read the FAQ entry under http://www.engelschall.com/sw/mod_ssl/docs/#FAQ-vhosts for more details. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
MSIE vs Client certs
Joost Stegeman wrote: >Which field did you add? Did you remember to use the -nobscrit option >to remove the critical contraint. MS doesn't like that in a (CA) >cert. This sounds promising - at our first shot of creating a CA, we skipped the 'State' field (can't remember the abbreviation of this field though). This since SSLeay says it's ok to skip fields, and since the field isn't very relevant in Sweden. The -nobscrit option in combination with creating a CA, have I frankly not heard of - could someone tell me more about it? I have quickly scanned through the FAQ for the PKCS12 CA-fix, and seen the term there - is it the same option? Thanks again, /Kenneth Pettersson __ Get Your Private, Free Email at http://www.hotmail.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: MSIE vs Client certs
On Wed, Nov 11, 1998, Kenneth Pettersson wrote: > Joost Stegeman wrote: > >Which field did you add? Did you remember to use the -nobscrit option > >to remove the critical contraint. MS doesn't like that in a (CA) >cert. > > This sounds promising - at our first shot of creating a CA, we skipped > the 'State' field (can't remember the abbreviation of this field > though). This since SSLeay says it's ok to skip fields, and since the > field isn't very relevant in Sweden. The -nobscrit option in combination > with creating a CA, have I frankly not heard of - could someone tell me > more about it? The "-nobscrit" stands for "No Basic Contraint Critical" and so the option says that the X.509 extension part named "Basic Constraint" is marked non-critical. It basically/usally means that browsers should not reject a cert just because they cannot handle this field. > I have quickly scanned through the FAQ for the PKCS12 CA-fix, and seen > the term there - is it the same option? Yes, and the CA-fix you've seen is the same as mod_ssl uses under `make certificate' (where -nobscrit is used, too). Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[BugDB] SSL server can't set private key (PR#45)
Full_Name: Peter Lister Version: Server Version: Apache/1.3.3 (Umod_ssl/2.0.15 SSLeay/0.9.0b OS: OSF1 neptune V4.0 564 alpha Submission from: neptune.pegasus.cranfield.ac.uk (138.250.1.185) My new apache with mod_ssl starts up fine, no config errors. I have a working Ben-SSL server and both the old server with Ben-SSL and the new one with mod_ssl use the same cert and key files. When I try to connect to the mod_ssl server the client reports an IO error and the server reports (in ssl_misc_log)... [11/Nov/1998:15:19:07 +] Unable to set private key [11/Nov/1998:15:19:07 +] ssl_int_SetCertStuff failed The key has no password, if that's relevant, and anyway, mod_ssl fails in the same way using the snakeoil cert and key. SSLeay makes OK and passes all its tests. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [BugDB] SSL server can't set private key (PR#45)
On Wed, Nov 11, 1998, [EMAIL PROTECTED] wrote: > Full_Name: Peter Lister > Version: Server Version: Apache/1.3.3 (Umod_ssl/2.0.15 SSLeay/0.9.0b > OS: OSF1 neptune V4.0 564 alpha [...] > [11/Nov/1998:15:19:07 +] Unable to set private key > [11/Nov/1998:15:19:07 +] ssl_int_SetCertStuff failed > > The key has no password, if that's relevant, and anyway, mod_ssl > fails in the same way using the snakeoil cert and key. > SSLeay makes OK and passes all its tests. Seems like you were bitten by either the gcc vs. alpha-gcc or the SSLeay+RSAref UINT problem. What platform id have you used for configuring SSLeay? When it was the generic "gcc" please re-build with "alpha-gcc". Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: New hooks API
On Tue, Nov 10, 1998 at 08:03:54PM +0300, Khimenko Victor wrote:
> May be while Ralf is busy with documentation things someone could take a look
> on subj. This is just "working demo", but it's working enough to be usable as
> replacement for mod_ssl 2.1b8 ! PLEASE, take a look and make suggestions. IMO
I like it. Can I use it in my own projects?
Pro's:
* Strong prototyping & type checking
(on a "by function" basis). => No need to pre-define the "allowed" signatures.
* Elegant automatic wrapping of the called functions into inlined functions
(prerequisite for the strong typechecking)
Con's:
* Should be run thru indent to conform to Ralf's coding style
(no offense intended ;-)
Questions:
* In the following code snippet, we create a static ap_hook_start_##hook_name
pointer "per module" (i.e., for each module trat includes the header).
Shouldn't it be a global list that's shared between modules? And if yes, you
can't initialize it to NULL.
+static struct ap_hook_struct_##hook_name { \
+ ap_hook_func_##hook_name hook_addr;\
+ struct ap_hook_struct_##hook_name* next; \
+} *ap_hook_start_##hook_name = NULL; \
> PLEASE, take a look... It was sended three times to list
> but looks like noone even notice it :-((
Yes, I saw you sent it but was too busy to have a closer look. Sorry if I'm too
late with my response. Did you send it to [EMAIL PROTECTED] too?
In the Headers I received, only the developers who received the 2.1b9-SNAP
package are mentioned.
Martin
--
<[EMAIL PROTECTED]> |Siemens Information and
Phone: +49-89-636-46021 |Communication Products
FAX: +49-89-636-47816 |81730 Munich, Germany
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: New hooks API
On Wed, 11 Nov 1998, Martin Kraemer wrote:
> On Tue, Nov 10, 1998 at 08:03:54PM +0300, Khimenko Victor wrote:
> > May be while Ralf is busy with documentation things someone could take a look
> > on subj. This is just "working demo", but it's working enough to be usable as
> > replacement for mod_ssl 2.1b8 ! PLEASE, take a look and make suggestions. IMO
>
> I like it. Can I use it in my own projects?
>
Oops. Completely forgot about copyright problem :-(( Add the following in
the ap_hook.c and use as permitted:
-- cut --
/*
* Copyright (c) 1998 Khimenko Victor. All rights reserved.
*
* Choose one of two licenses:
*
*
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following
*disclaimer in the documentation and/or other materials
*provided with the distribution.
*
* 3. All advertising materials mentioning features or use of this
*software must display the following acknowledgment:
*"This product includes software developed by
* Khimenko Victor <[EMAIL PROTECTED]> for use in the
* mod_ssl project (http://www.engelschall.com/sw/mod_ssl/)."
* except when used in mod_ssl-derived or Apache-derived products.
*
* 4. The names "mod_ssl" must not be used to endorse or promote
*products derived from this software without prior written
*permission. For written permission, please contact
*[EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "mod_ssl"
*nor may "mod_ssl" appear in their names without prior
*written permission of Ralf S. Engelschall.
*
* 6. Redistributions of any form whatsoever must retain the following
*acknowledgment:
*"This product includes software developed by
* Khimenko Victor <[EMAIL PROTECTED]> for use in the
* mod_ssl project (http://www.engelschall.com/sw/mod_ssl/)."
*
* THIS SOFTWARE IS PROVIDED BY KHIMENKO VICTOR ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL KHIMENKO VICTOR OR
* HIS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
*
*
* This is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This code is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License (http://www.gnu.org/copyleft/lgpl.html)
* for more details.
* =
*/
-- cut --
> Pro's:
> * Strong prototyping & type checking
> (on a "by function" basis). => No need to pre-define the "allowed" signatures.
>
> * Elegant automatic wrapping of the called functions into inlined functions
> (prerequisite for the strong typechecking)
>
> Con's:
> * Should be run thru indent to conform to Ralf's coding style
> (no offense intended ;-)
>
> Questions:
> * In the following code snippet, we create a static ap_hook_start_##hook_name
> pointer "per module" (i.e., for each module trat includes the header).
> Shouldn't it be a global list that's shared between modules? And if yes, you
> can't initialize it to NULL.
> +static struct ap_hook_struct_##hook_name { \
> + ap_hook_func_##hook_name hook_addr;\
> + struct ap_hook_struct_##hook_name* next; \
> +} *ap_hook_start_##hook_name = NULL; \
>
No, it's not possible. Consider situation where mod_ssl and mod_perl are
hooked, for example (DSO case). We could not put variable in mod_ssl
since mod_perl should be load
