Return-Path: X-Original-To: apmail-httpd-users-archive@www.apache.org Delivered-To: apmail-httpd-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DE53C10AF6 for ; Thu, 17 Apr 2014 20:00:47 +0000 (UTC) Received: (qmail 13178 invoked by uid 500); 17 Apr 2014 20:00:25 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 13133 invoked by uid 500); 17 Apr 2014 20:00:24 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 13012 invoked by uid 99); 17 Apr 2014 20:00:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Apr 2014 20:00:22 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.216.51] (HELO mail-qa0-f51.google.com) (209.85.216.51) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Apr 2014 20:00:18 +0000 Received: by mail-qa0-f51.google.com with SMTP id j7so821739qaq.38 for ; Thu, 17 Apr 2014 12:59:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dCU8sWortz4zKfQIvhCd9oaQJALnwitwtP7yXVIipw8=; b=aOS/DY5ik/q5egqsChQguGip1PmTZW5A/rKW7Y5/EYDFBaQ6bfRkzYtIGZPi4I/DDA 0/GaoehtUFaJ4V2LRVJ2Lu5iQjyzxFQZcAlGEaTUnvrxsiGbNSOnZpeYKOHZi9RaXp11 WmCsrCKZ4lU3CRVf4FfUqyVG6m1ga4TaQGL+udLwn35ZNjMurj1X/G4wv9krIPv0ztGu U1yWireOSNCz5FLyiCqaFZj6WwV7+4BkDdeMS0WBcV1vUhrlGz9LKFsibg0ACPtMYmGB GU3Q594XfBahUHZVkAMlJ6cmKFa1ankDHfz/bYIb3+zRgFu6fAKrfRNxbjGUCnV9AVRJ qc+A== X-Gm-Message-State: ALoCoQn0mVqWF6VHOWwwVQfAZoeTATM0oRVQCdQZjIJJ68Y1huGyin1GwZVDlAxuKOYyMvTt27px MIME-Version: 1.0 X-Received: by 10.140.101.244 with SMTP id u107mr5310207qge.107.1397764797918; Thu, 17 Apr 2014 12:59:57 -0700 (PDT) Received: by 10.224.201.73 with HTTP; Thu, 17 Apr 2014 12:59:57 -0700 (PDT) In-Reply-To: References: <53502786.2000300@psfc.mit.edu> Date: Thu, 17 Apr 2014 13:59:57 -0600 Message-ID: From: Mark Brodis To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=001a11c1677242859104f7427aa9 X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] HTTPS configuration problem. --001a11c1677242859104f7427aa9 Content-Type: text/plain; charset=UTF-8 Do the users actually connect to "https://xxx.com" ? Or do they go just to "xxx.com" in their browser and then a load-balancer/SSL-accellerator somewhere along the way bumps them to https? If something was bumping them to https then it would be easiest to just change that 'bumping' to go from "http://xxx.com" to "https://www.xxx.com", which ofcourse any webserver could do (with a default document with a meta-refresh), but most content-source-switches or local-traffic-managers/loadbalancers could do right in the config (i.e. they respond to the GET / with a HTTP 302 go-over-here, etc), i.e. actually function as a limited in-line web-server. Good luck... On Thu, Apr 17, 2014 at 1:46 PM, Yehuda Katz wrote: > On Thu, Apr 17, 2014 at 3:12 PM, Mark London wrote: > >> So I've been trying to find a configuration that redirects >> HTTPS://XXX.COM to HTTPS://WWW.XXX.COM. Unfortunately, every >> configuration that I've tried, doesn't work. All of the rewrite and >> redirect rules, are applied after the browser checks the certificate >> against the URL. Thus, the warning web page always appears. >> > > This is the expected behavior and other than issuing a new certificate and > using another vhost (with SNI - generally not compatible with Windows XP > and some other devices) or reissuing the same certificate with an > additional name, there is no way around this. > > - Y > --001a11c1677242859104f7427aa9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do the users actually connect to "https://xxx.com" ?=C2=A0 Or do they go just to "= ;xxx.com" in their browser and then a l= oad-balancer/SSL-accellerator somewhere along the way bumps them to https?<= br>
If something was bumping them to https then it would be easiest to just= change that 'bumping' to go from "= http://xxx.com" to "https://w= ww.xxx.com", which ofcourse any webserver could do (with a default= document with a meta-refresh), but most content-source-switches or local-t= raffic-managers/loadbalancers could do right in the config (i.e. they respo= nd to the GET / with a HTTP 302 go-over-here, etc), i.e. actually function = as a limited in-line web-server.

Good luck...


On Thu, Apr 17, 2014 at 1:46 PM, Yehuda Katz <yehuda@= ymkatz.net> wrote:
=
On Thu, Apr 17, 2014 at 3:12 PM,= Mark London <mrl@psfc.mit.edu> wrote:
So I've been trying to find a configurat= ion that redirects HTTPS://XX= X.COM to HTTPS://WWW.= XXX.COM. =C2=A0Unfortunately, every configuration that I've tried, = doesn't work. =C2=A0All of the rewrite and redirect rules, are applied = after the browser checks the certificate against the URL. =C2=A0 Thus, the = warning web page always appears.

This is the expected behavior and ot= her than issuing a new certificate and using another vhost (with SNI - gene= rally not compatible with Windows XP and some other devices) or reissuing t= he same certificate with an additional name, there is no way around this.

- Y

--001a11c1677242859104f7427aa9--