Hello everyone,
Part of our website has secured access with an SSL certificate. The problem we are running into is that the certificate is for www.domainname.com, so when they go to domainname.com (without the www. in front), the users are getting a "This connection is untrusted" warning, because the url doesn't match the certificate.
I found one site that said to make a change to the apache conf file, which I have done. The change that I made is adding: <VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost>
This works great to redirect the users to http://www.domainname.com when they go to http://domainname.com.
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
I tried using the same thing as above, but changing the port number to 443, and the http to https on the redirect line, but that actually breaks the site, and only displays an error: Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
Is there something obvious that I am missing? Is there a better way to ensure that everyone will always end up with the www in the url, so the certificate always matches?
Any thoughts and suggestions would be greatly appreciated.
On Wed, 2010-05-19 at 14:08 -0600, Ski Dawg wrote:
Hello everyone,
Part of our website has secured access with an SSL certificate. The problem we are running into is that the certificate is for www.domainname.com, so when they go to domainname.com (without the www. in front), the users are getting a "This connection is untrusted" warning, because the url doesn't match the certificate.
I found one site that said to make a change to the apache conf file, which I have done. The change that I made is adding:
<VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost>
This works great to redirect the users to http://www.domainname.com when they go to http://domainname.com.
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
I tried using the same thing as above, but changing the port number to 443, and the http to https on the redirect line, but that actually breaks the site, and only displays an error: Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
Is there something obvious that I am missing? Is there a better way to ensure that everyone will always end up with the www in the url, so the certificate always matches?
---- yes, put the same VirtualHost directive into /etc/httpd/conf.d/ssl.conf
Craig
On Wed, May 19, 2010 at 2:13 PM, Craig White craigwhite@azapple.com wrote:
On Wed, 2010-05-19 at 14:08 -0600, Ski Dawg wrote:
I found one site that said to make a change to the apache conf file, which I have done. The change that I made is adding:
<VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost> the certificate always matches?
yes, put the same VirtualHost directive into /etc/httpd/conf.d/ssl.conf
Thanks for the quick response Craig.
In our ssl.conf file, our domain is not set up. The ssl configuration for our domain is in our httpd.conf file. Is there a particular place to put this redirect or can it just go at the end of the ssl.conf file?
In our httpd.conf file, we have: <IfDefine SSL>
<VirtualHost xxx.xxx.xxx.xxx:443> ServerName www.domainname.com ServerAlias domainname.com DocumentRoot /home/username/public_html UseCanonicalName off
BytesLog /usr/local/apache/domlogs/domainname.com-bytes_log ScriptAlias /cgi-bin/ /home/username/public_html/cgi-bin/ SSLEngine on SSLCertificateFile /etc/ssl/certs/domainname.com.crt SSLCertificateKeyFile /etc/ssl/private/domainname.com.key SSLLogFile /usr/local/apache/domlogs/domainname.com-ssl_data_log CustomLog /usr/local/apache/domlogs/domainname.com-ssl_log combined SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown </VirtualHost> </IfDefine>
I had tried adding the redirect section into this area in our httpd.conf file, inside the Virtualhost section, within the IfDefine, but outside the VirtualHost section, but it still kept giving me the error Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
At Wed, 19 May 2010 14:08:59 -0600 CentOS mailing list centos@centos.org wrote:
Hello everyone,
Part of our website has secured access with an SSL certificate. The problem we are running into is that the certificate is for www.domainname.com, so when they go to domainname.com (without the www. in front), the users are getting a "This connection is untrusted" warning, because the url doesn't match the certificate.
I found one site that said to make a change to the apache conf file, which I have done. The change that I made is adding:
<VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost>
You don't really need this -- you can just add the line below to your existing <VirtualHost> spec for www.domainname.com
ServerAlias domainname.com
This works great to redirect the users to http://www.domainname.com when they go to http://domainname.com.
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
I tried using the same thing as above, but changing the port number to 443, and the http to https on the redirect line, but that actually breaks the site, and only displays an error: Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
Probably because the VirtualHost for domainname.com:443 does not include the SSL cert info. You can try including a ServerAlias line to your VirtualHost:443 container for www.domainname.com.
The only other thought would be look at your DNS record(s) for domainname.com and make sure those records are 'sane' (in terms of which name has the IP address and which is a CNAME record).
Is there something obvious that I am missing? Is there a better way to ensure that everyone will always end up with the www in the url, so the certificate always matches?
Any thoughts and suggestions would be greatly appreciated.
On Wed, May 19, 2010 at 2:33 PM, Robert Heller heller@deepsoft.com wrote:
At Wed, 19 May 2010 14:08:59 -0600 CentOS mailing list centos@centos.org wrote:
<VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost>
You don't really need this -- you can just add the line below to your existing <VirtualHost> spec for www.domainname.com
ServerAlias domainname.com
This doesn't work. This is what we had before. When you just add the ServerAlias domainname.com to the VirtualHost configuration, when the user goes to http://domainname.com, it stays on http://domainname.com, and does not redirect to http://www.domainname.com. We need to have it go to http://www.domainname.com so that when they click a link on out site that then takes them to https://www.domainname.com so that it matches the SSL certificate.
I tried using the same thing as above, but changing the port number to 443, and the http to https on the redirect line, but that actually breaks the site, and only displays an error: Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
Probably because the VirtualHost for domainname.com:443 does not include the SSL cert info. You can try including a ServerAlias line to your VirtualHost:443 container for www.domainname.com.
That is already done, and still is giving us the SSL error, when trying to do a redirect.
The only other thought would be look at your DNS record(s) for domainname.com and make sure those records are 'sane' (in terms of which name has the IP address and which is a CNAME record).
I believe this is correct, but I will double check that. Thanks for the suggestion.
At Wed, 19 May 2010 15:21:06 -0600 CentOS mailing list centos@centos.org wrote:
On Wed, May 19, 2010 at 2:33 PM, Robert Heller heller@deepsoft.com wrote:
At Wed, 19 May 2010 14:08:59 -0600 CentOS mailing list centos@centos.org wrote:
<VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost>
You don't really need this -- you can just add the line below to your existing <VirtualHost> spec for www.domainname.com
ServerAlias domainname.com
This doesn't work. This is what we had before. When you just add the ServerAlias domainname.com to the VirtualHost configuration, when the user goes to http://domainname.com, it stays on http://domainname.com, and does not redirect to http://www.domainname.com. We need to have it go to http://www.domainname.com so that when they click a link on out site that then takes them to https://www.domainname.com so that it matches the SSL certificate.
The https: URL should be an absolute, fully qualified URL and *explicitly* have the www.domainname.com hostname. It should NOT be a relative URL or any other games, including PHP/Perl/etc/ code that (blindly) uses the SERVER_NAME environment variable -- that is the code should either have the proper URL hard-wired OR should programatically check SERVER_NAME for the presense of the 'www.' in the front (eg if NOT regexp '^www.' SERVER_NAME then prepend 'www.' onto SERVER_NAME). It should not matter what name is being used to access the non-SSL side of the side.
I tried using the same thing as above, but changing the port number to 443, and the http to https on the redirect line, but that actually breaks the site, and only displays an error: Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
Probably because the VirtualHost for domainname.com:443 does not include the SSL cert info. You can try including a ServerAlias line to your VirtualHost:443 container for www.domainname.com.
That is already done, and still is giving us the SSL error, when trying to do a redirect.
The only other thought would be look at your DNS record(s) for domainname.com and make sure those records are 'sane' (in terms of which name has the IP address and which is a CNAME record).
I believe this is correct, but I will double check that. Thanks for the suggestion.
On 05/19/2010 04:08 PM, Ski Dawg wrote:
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
Is there something obvious that I am missing? Is there a better way to ensure that everyone will always end up with the www in the url, so the certificate always matches?
The problem you are running into is that SSL sessions are negotiated prior to the browser sending the virtual host name, so there is no opportunity to redirect the client to the www URL before it's too late. Aside from purchasing a second SSL certificate for the plain domain name or getting a wildcard certificate to cover both, I would just make sure the links on your web site to the secure version of the domain specify the www in the URL.
-Zack
On Wed, May 19, 2010 at 3:02 PM, Zack Colgan security-watch-zack@clearbearing.com wrote:
On 05/19/2010 04:08 PM, Ski Dawg wrote:
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
The problem you are running into is that SSL sessions are negotiated prior to the browser sending the virtual host name, so there is no opportunity to redirect the client to the www URL before it's too late. Aside from purchasing a second SSL certificate for the plain domain name or getting a wildcard certificate to cover both, I would just make sure the links on your web site to the secure version of the domain specify the www in the URL.
Zack,
Thanks for the reply.
All of our links use the correct syntax (with the www), we were just trying to catch the corner cases where if someone tries to go directly to https://domainname.com instead of https://www.domainname.com then it would not give them the error.
I was hoping to be able to do this without another certificate, since this is just some corner cases, but I will investigate that as well. Thanks.
Ski Dawg wrote:
On Wed, May 19, 2010 at 3:02 PM, Zack Colgan security-watch-zack@clearbearing.com wrote:
On 05/19/2010 04:08 PM, Ski Dawg wrote:
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
The problem you are running into is that SSL sessions are negotiated prior to the browser sending the virtual host name, so there is no opportunity to redirect the client to the www URL before it's too late. Aside from purchasing a second SSL certificate for the plain domain name or getting a wildcard certificate to cover both, I would just make sure the links on your web site to the secure version of the domain specify the www in the URL.
Zack,
Thanks for the reply.
All of our links use the correct syntax (with the www), we were just trying to catch the corner cases where if someone tries to go directly to https://domainname.com instead of https://www.domainname.com then it would not give them the error.
I was hoping to be able to do this without another certificate, since this is just some corner cases, but I will investigate that as well. Thanks.
You might try rewrite instead of redirect. It would seem that rewrite might happen before processing the certificate.
Here's an example of where I've used rewrite, you'll have to substitute the correct regular expressions for your needs. Also see RewriteCond of needed... RewriteEngine On RewriteRule ^/$ https://www.myhost.org/
Let us know if this works for you.
There are also mechanisms to create single certificates with multiple domainnames. There are apparently many ways to do this, and only certain of these methods work with various http servers and/or browsers. I've not spent the time to fully understand this (I tried it briefly with cacert.org and never got it working), though if you just recently purchased the certificate and you are having a problem, most of the CA's will redo the certificate. You might ask your CA what they recommend in this case.
Nataraj
At Wed, 19 May 2010 15:29:51 -0600 CentOS mailing list centos@centos.org wrote:
On Wed, May 19, 2010 at 3:02 PM, Zack Colgan security-watch-zack@clearbearing.com wrote:
On 05/19/2010 04:08 PM, Ski Dawg wrote:
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
The problem you are running into is that SSL sessions are negotiated prior to the browser sending the virtual host name, so there is no opportunity to redirect the client to the www URL before it's too late. Aside from purchasing a second SSL certificate for the plain domain name or getting a wildcard certificate to cover both, I would just make sure the links on your web site to the secure version of the domain specify the www in the URL.
Zack,
Thanks for the reply.
All of our links use the correct syntax (with the www), we were just trying to catch the corner cases where if someone tries to go directly to https://domainname.com instead of https://www.domainname.com then it would not give them the error.
Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that. If people are doing this, then that means there is some reason for it (maybe the https://www.domtainname.com/... link is too deeply burried in the regular site?).
I was hoping to be able to do this without another certificate, since this is just some corner cases, but I will investigate that as well. Thanks.
On Wed, May 19, 2010 at 3:52 PM, Robert Heller heller@deepsoft.com wrote:
Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that. If people are doing this, then that means there is some reason for it (maybe the https://www.domtainname.com/... link is too deeply burried in the regular site?).
No, I don't think there is a legitimate reason for it, but it came up as a possible situation during our testing, so they wanted me to fix that issue as well. As far as I know, no one actually every types in https://domainname.com, but management wants it fixed anyway. So that is why I asked the question.
if they were to go to the proper front page of our site, and just click through links, they would end up on a https://www.domainname.com site, and the certificate would work. I think they are just wanting to remove everything that could possibly be an error, even if it is only a self-generated error.
At Wed, 19 May 2010 16:36:00 -0600 CentOS mailing list centos@centos.org wrote:
On Wed, May 19, 2010 at 3:52 PM, Robert Heller heller@deepsoft.com wrote:
Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that. If people are doing this, then that means there is some reason for it (maybe the https://www.domtainname.com/... link is too deeply burried in the regular site?).
No, I don't think there is a legitimate reason for it, but it came up as a possible situation during our testing, so they wanted me to fix that issue as well. As far as I know, no one actually every types in https://domainname.com, but management wants it fixed anyway. So that is why I asked the question.
if they were to go to the proper front page of our site, and just click through links, they would end up on a https://www.domainname.com site, and the certificate would work. I think they are just wanting to remove everything that could possibly be an error, even if it is only a self-generated error.
Do you have logs / Google Analytics reports that show that visitors are actually landing on https://www.domainname.com (other than your testing)? If not, you can show this to management.
On Thu, May 20, 2010 at 5:25 AM, Robert Heller heller@deepsoft.com wrote:
Do you have logs / Google Analytics reports that show that visitors are actually landing on https://www.domainname.com (other than your testing)? If not, you can show this to management.
Thanks to everyone else for the replies on this topic. I scanned through all of the logs for the last month, and this has only come up twice in that entire time, and I believe they change that I made to redirect them to http://www.domainname.com (instead of http://domainname.com) would have caught both of those instances.
I brought those numbers up to my managers, and was able to convince them that this isn't worth any more of my time.
Thanks to everyone for all of the feedback and assistance. It is greatly appreciated.
On 05/21/2010 02:02 PM, Ski Dawg wrote:
Thanks to everyone else for the replies on this topic. I scanned through all of the logs for the last month, and this has only come up twice in that entire time, and I believe they change that I made to redirect them to http://www.domainname.com (instead of http://domainname.com) would have caught both of those instances.
Not sure what you mean by "caught", but to reiterate: You cannot prevent popups with a redirect. The redirect will be sent after the user has already seen the warning. You can only prevent the warning by using different certs on different IPs, or using a cert with additional valid names and SNI (which isn't available in the vendor's package in RHEL 5).
On 5/19/2010 4:52 PM, Robert Heller wrote:
Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that.
How else would you get there the first time?
On Wed, May 19, 2010 at 4:43 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 5/19/2010 4:52 PM, Robert Heller wrote:
Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that.
How else would you get there the first time?
By default, most of our site is not SSL encrypted, just when they would go to specific areas, like shopping cart, etc, that we switch to https. If they just follow the links on our site, and not manually type in the incorrect one, it will take them to the https://www.domainname.com/..... part of the site and the SSL certificate will work as expected.
The only time this error occurs is if the user were to manually type in the location bar in their browser https://domainname.com.
After some of the replies to this thread, I checked back through the access logs and this situation has only happened 2 times in the last month.
I think that I am going to push at management that this is a non-issue and not worth wasting any more time and see what they might say.
I think that I am going to push at management that this is a non-issue and not worth wasting any more time and see what they might say.
I'd like to point out that the following sites don't work with https://domain.tld/
amazon.com usbank.com redhat.com etrade.com
They all present certs for www.domain.tld. If your management feels that your sites would benefit greatly from this type of configuration while the above sites don't feel it to be necessary, I recommend that they try the same test on similar large sites, and if applicable, competitor's sites.
The most compatible way to do this is to have domain.tld and www.domain.tld resolve to different IP addresses, and have 2 certs, one for each name on their respective IP addresses. TLS SNI can solve this with a single IP address in Fedora 12+ and RHEL 6+ (the latter of which doesn't exist yet) although this requires browser support of TLS SNI. Simply put, MS IE 6 doesn't support it, which is deeply entrenched in corporations. Firefox 2.0+ supports it as do other browsers.
As for the redirection, I would handle it with mod_rewrite as follows:
<VirtualHost XXX.XXX.XXX.XXX:443> ServerName domain.tld RewriteCond %{HTTP_HOST} !^www.domain.tld$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) https://www.domain.tld/$1 [L,R=301] </VirtualHost>
Hope this helps.
Barry
On Wed, May 19, 2010 at 7:45 PM, Barry Brimer lists@brimer.org wrote:
As for the redirection, I would handle it with mod_rewrite as follows:
<VirtualHost XXX.XXX.XXX.XXX:443> ServerName domain.tld RewriteCond %{HTTP_HOST} !^www\.domain\.tld$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) https://www.domain.tld/$1 [L,R=301] </VirtualHost>
Barry and Jobst,
Thanks for the rewrite suggestions. I will file them away and give them a try when I come back to this issue, sometime in the future.
On 21 May 2010 22:04, Ski Dawg centos@skidawg.org wrote:
On Wed, May 19, 2010 at 7:45 PM, Barry Brimer lists@brimer.org wrote:
As for the redirection, I would handle it with mod_rewrite as follows:
<VirtualHost XXX.XXX.XXX.XXX:443> ServerName domain.tld RewriteCond %{HTTP_HOST} !^www\.domain\.tld$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) https://www.domain.tld/$1 [L,R=301] </VirtualHost>
Barry and Jobst,
Thanks for the rewrite suggestions. I will file them away and give them a try when I come back to this issue, sometime in the future. -- Doug
Registered Linux User #285548 (http://counter.li.org)
Never trust a computer you can't throw out a window. -- Steve Wozniak _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Those rewrite suggestions will not accomplish in solving the problem you presented....
I wish people would actually read through the replies before suggesting something that has already been shown not to work ^^
James
On 21 May 2010 22:04, Ski Dawg centos@skidawg.org wrote:
On Wed, May 19, 2010 at 7:45 PM, Barry Brimer lists@brimer.org wrote:
As for the redirection, I would handle it with mod_rewrite as follows:
<VirtualHost XXX.XXX.XXX.XXX:443> ServerName domain.tld RewriteCond %{HTTP_HOST} !^www\.domain\.tld$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) https://www.domain.tld/$1 [L,R=301] </VirtualHost>
Those rewrite suggestions will not accomplish in solving the problem you presented....
I wish people would actually read through the replies before suggesting something that has already been shown not to work ^^
James,
Perhaps you didn't notice the part in my message where I indicated that this would require separate IP addresses with appropriate certs on each, such as domain.tld and www.domain.tld. My example does not include important things that are part of the configuration already to serve an https website with mod_rewrite support such as:
SSLEngine On SSLCertificateFile ... SSLCertificateKeyFile ... RewriteEngine On ... etc
I am surprised to hear that this doesn't work since it works fine for me. What part do you feel doesn't work?
Barry
On 22 May 2010 00:00, Barry Brimer lists@brimer.org wrote:
On 21 May 2010 22:04, Ski Dawg centos@skidawg.org wrote:
On Wed, May 19, 2010 at 7:45 PM, Barry Brimer lists@brimer.org wrote:
As for the redirection, I would handle it with mod_rewrite as follows:
<VirtualHost XXX.XXX.XXX.XXX:443> ServerName domain.tld RewriteCond %{HTTP_HOST} !^www\.domain\.tld$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) https://www.domain.tld/$1 [L,R=301] </VirtualHost>
Those rewrite suggestions will not accomplish in solving the problem you presented....
I wish people would actually read through the replies before suggesting something that has already been shown not to work ^^
James,
Perhaps you didn't notice the part in my message where I indicated that this would require separate IP addresses with appropriate certs on each, such as domain.tld and www.domain.tld. My example does not include important things that are part of the configuration already to serve an https website with mod_rewrite support such as:
SSLEngine On SSLCertificateFile ... SSLCertificateKeyFile ... RewriteEngine On ... etc
I am surprised to hear that this doesn't work since it works fine for me. What part do you feel doesn't work?
Barry _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sorry Barry I wasn't referring to you and was being fairly grumpy... it was to Jobst and the others - you're post was indeed details in SNI or certificate requirements.... There were a few who chimed in with mod_rewrite suggestions but ignored the requirement of the SSL cert and no invalid cert warning popping up for the users...
James
At Wed, 19 May 2010 17:43:14 -0500 CentOS mailing list centos@centos.org wrote:
On 5/19/2010 4:52 PM, Robert Heller wrote:
Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that.
How else would you get there the first time?
Through a link/form from http://www.domainname.com. It other words, all *landing* pages are on the non-SSL side of the site, whether by direct traffic or through external links. While it is possible to *bookmark* a page on the SSL side, the URL by then *should* be properly qualified (with the leading www., as defined in the cert.). The OP should make sure that all links to the SSL side include the www. and to make sure the site is properly structured with a link/form for the SSL side at some convienent point. Visitors should NOT be forced to follow too many links (clicks) to get there. Eg if this is a shopping cart checkout or a secure login, a link should be included in the header or sidebar navigation on the front page and/or every possible landing page.
At Wed, 19 May 2010 17:02:31 -0400 CentOS mailing list centos@centos.org wrote:
On 05/19/2010 04:08 PM, Ski Dawg wrote:
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
Is there something obvious that I am missing? Is there a better way to ensure that everyone will always end up with the www in the url, so the certificate always matches?
The problem you are running into is that SSL sessions are negotiated prior to the browser sending the virtual host name, so there is no opportunity to redirect the client to the www URL before it's too late. Aside from purchasing a second SSL certificate for the plain domain name or getting a wildcard certificate to cover both, I would just make sure the links on your web site to the secure version of the domain specify the www in the URL.
Also: don't 'advertise' the https:// URL at all. Visitors should always go to you non-SSL site first.
-Zack _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/19/2010 02:02 PM, Zack Colgan wrote:
The problem you are running into is that SSL sessions are negotiated prior to the browser sending the virtual host name, so there is no opportunity to redirect the client to the www URL before it's too late. Aside from purchasing a second SSL certificate for the plain domain name or getting a wildcard certificate to cover both
Unless your HTTPD supports SNI, a second certificate alone isn't going to do you any good. AFAIK, under CentOS 5, there is only one solution to this problem: a certificate with multiple alt-names (or wildcard).
SNI should be a feature of RHEL 6. I believe that it's been available in Fedora since release 11.
There is a configuration where a second cert will work, but you'd need an additional IP. If you run "domainname.com" on one IP with a matching cert and "www.domainname.com" on a separate IP with its matching cert, users won't get errors. Two certs will usually cost more than one cert with an alt-name, but less than throwing away your old cert to get a new cert with both names.
put this into root of the domain into the .htaccess file
RewriteCond %{HTTP_HOST} !^www. [NC] RewriteCond %{REMOTE_HOST} !^.*YOURDOMAIN.com [NC] RewriteRule ^(.*)$ http://www.%%7BHTTP_HOST%7D/$1 [R=301,L]
Jobst
On Wed, May 19, 2010 at 02:08:59PM -0600, Ski Dawg (centos@skidawg.org) wrote:
Hello everyone,
Part of our website has secured access with an SSL certificate. The problem we are running into is that the certificate is for www.domainname.com, so when they go to domainname.com (without the www. in front), the users are getting a "This connection is untrusted" warning, because the url doesn't match the certificate.
I found one site that said to make a change to the apache conf file, which I have done. The change that I made is adding:
<VirtualHost xxx.xxx.xxx.xxx:80> ServerName domainname.com Redirect permanent / http://www.domainname.com/ </VirtualHost>
This works great to redirect the users to http://www.domainname.com when they go to http://domainname.com.
The problem I am running into is if they go to https://domainname.com (straight to the secure site), I am not able to find a solution that will redirect them to https://www.domainname.com, so that the ssl certificate matches and they won't get the "This connection is untrusted" warning.
I tried using the same thing as above, but changing the port number to 443, and the http to https on the redirect line, but that actually breaks the site, and only displays an error: Secure Connection Failed (Error code: ssl_error_rx_record_too_long)
Is there something obvious that I am missing? Is there a better way to ensure that everyone will always end up with the www in the url, so the certificate always matches?
Any thoughts and suggestions would be greatly appreciated.
Doug
Registered Linux User #285548 (http://counter.li.org)
Never trust a computer you can't throw out a window. -- Steve Wozniak _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Barry Brimer -
Craig White -
Gordon Messmer -
James Hogarth -
Jobst Schmalenbach -
Les Mikesell -
Nataraj -
Robert Heller -
Ski Dawg -
Zack Colgan