5

Like the subject says I need to rewrite https://domain.com => https://www.domain.com. But I have a wildcard SSL setup for the domain and the root domain does not match *.domain.com, thus the browser brings up an error

domain.com uses an invalid security certificate.

The certificate is only valid for *.domain.com

This is my current vhost config

<VirtualHost 127.0.0.1:443> ServerAdmin [email protected] DocumentRoot /usr/local/app/domain/webapps/www JkMount /* somestuff ServerName domain. com ServerAlias www.domain.com ErrorLog logs/domain.com-error_log CustomLog logs/domain.com-access_log combined Customlog logs/domain.com-deflate_log deflate RewriteEngine on RewriteCond %{HTTP_HOST} ^domain\.com [NC] RewriteRule ^/?(.*) https://www.domain.com/$1 [L,R,NE] SSLEngine on SSLCertificateFile /etc/httpd/conf/ssl.crt/x.domain.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/x.domain.com.key </VirtualHost> 

I was hoping that the RewriteEngine would kick in before the SSL is loaded but doesn't work. Is this solvable without getting a new cert that is just for the root domain ?

0

3 Answers 3

6

Unfortunately the name that the client is talking to is checked against the certificate by the client, not the server. As far as the client is concerned it is talking to domain.com not <something>.domain.com - it will be unaware of any URL rewriting that is being done at the server end.

So you will need an extra certificate for the other name to avoid certificate errors.

5
  • This is correct. SSL negotiation will always happen first. Commented Nov 21, 2009 at 18:15
  • 2
    One could argue that it's rather "fortunate" that the client checks itself, not unfortunate. If the redirect could happen prior to SSL negotiation, traffic would obviously not be encrypted and a man in the middle could redirect the client anywhere they want to. This extra certificate usually costs money, which is unfortunate :) Commented Feb 20, 2010 at 8:12
  • 1
    Also, you might be able to get both, the wildcard and the toplevel domain in just one certificate - see the answers to serverfault.com/questions/87005/…. I've not tried that, but this way you could work with just one certificate (and on the same IP address) instead of requiring an extra IP address just for the top level address. Commented Feb 20, 2010 at 8:15
  • I agre, but it is unfortunate for the person asking the question as it impacts what is trying to do (serve both addresses so redirection works smoothly but with one certificate). Security is a GoodThing(tm), unfortunately being secure isn't always convinient. Commented Feb 20, 2010 at 18:44
  • I was looking for this answer everywhere. I'd assumed as much, but wanted to be sure. Thanks. +1 Commented May 20, 2011 at 21:53
0

The host headers are (normally) not visible without terminating the SSL connection, so the certificate needs to be valid for whatever the client is entering... you could rewrite http://domain.com to https://www.domain.com though (why the heck did the comment code remove the www. when it made the examples into an url for? ^^)

0

It looks like the DigiCert SSL Plus will do this for you.

With DigiCert's innovative use of Subject Alternative Names, your DigiCert SSL Plus certificate will secure both www.example.com and example.com (with and without the www!), leaving less potential for browser warnings.

1
  • The word "innovative" doesn't fit here as multi-name certificates are part of the standard - you just usually get charged more for having such a certificate signed just as you do for wildcard certificates, and not all CAs offer them as a product. They work the same way: the browser connects to what it thinks is www.domain.tld or domain.tld and gets a cert back that is valid for both and it is happy (in the case of a wildcard cert it would be presented with one that is valid for <anything>.domain.tld Commented May 21, 2011 at 1:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.