Apache HTTPS problem

Hi,
I am trying to change an Apache under CentOS 7 to HTTPS. At the moment this works only partially.

Servername wiki01.xx.yy

DocumentRoot /var /www/ html

In/var /www /html are several subdirectories that contain different mediawikis

/var /www/html/ mediawiki1
/var/www /html/ mediawiki2
...

When I visit https://wiki01.xx.yy, I see the Apache test page (test page 123 ..) and the page shows the correct certificate.

When I call https://wiki01.xx.yy/mediawiki1, the page is shown as http://wiki01.xx.yy/mediawiki1 and shows that the page is not secure.

I have already tried various solutions (directory, alias entries, etc.) from the Internet, but no success. Either the sites are shown without ssl or I cannot access the pages at all.

Maybe someone can help me with this problem.

Thank you.

You didnt specify what type of cert you aquired, so I am assuming that you have one cert per domain.

Apache uses either ip based virtual servers or name based name based.
If you are sharing a single ip address and name based virtual servers, then you will only be able to use one certificate. However, if you have seperate ip addresses per virtual server then you must specify both addresses to the server (not sure if you are routing to your server or running direct). In Apache site config file, you must specify the virtual server and in each virtual server you must specify the ssl certificate and associated key files:

NameVirtualHost *:443

<VirtualHost *:443>
ServerName www.yoursite.com
DocumentRoot /var/www/site
SSLEngine on
SSLCertificateFile /path/to/www_yoursite_com.crt SSLCertificateKeyFile /path/to/www_yoursite_com.key SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>

<VirtualHost *:443>
ServerName www.yoursite2.com
DocumentRoot /var/www/site2
SSLEngine on
SSLCertificateFile /path/to/www_yoursite2_com.crt SSLCertificateKeyFile /path/to/www_yoursite2_com.key SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>

Make sure that apache has read access to these files but not be in the document root.

All of the required reading is found on the Apache.org website, a quick google search will yeild this and more.

#2 is an excellent explanation, but it doesn't appear to address the OPs question. I particularly like the reference to the apache documentation, which is through and comprehensive on the subject.

As I read it, the OP has page(s) on a secure domain for which address bar is changing back to http:// -- this is not the same as can occur where there are insecure content on a secure page. In that case, the browser (at least Firefox does it this way) changes the color of the padlock, but still retains the https:// in the address bar. That insecure content can simply be a link to a non-secure domain.

Do other browsers do it differently? Elim Garak, what browser are you using?
Do you have any content within the mediawiki1x pages that is not secure?

If you read the question, the OP is visiting a https page that is redirected to http. This is done by apache due to a misconfiguration of the site conf. Apache will send a soft redirect to the browser if https is requested but only http is available for the request. Its is expected behavior with name based virtualhosts, the corect way to fix this is to use ip based virtual hosts or have a wildcard domain certificate. Make sure you also setup 305 redirects from http to https in your config and dont mix ip based with name based configs or apache will do very interesting things at random(things I learned the hard way that nearly cost me my sanity, or what was left of it.)

To be absolutely honest, apache name based virtual hosts can use different ssl certificates but the pain and complexity to get it to work is quite painful and if it breaks, you will be truely on your own.

I believe name based virtual hosting has been deprecated in apache 2.4 -- I seem to recall getting warnings about that when I upgraded.

That said, you're probably right. The reason that the OP is having the problem is because they've not configured their http redirection to https correctly. We do it like this in the VirtualHost for port 80:

Redirect permanent / https://mydomain.com/

and then a full blown VirtualHost definition for port 443...

I think we need to see what the OP has done...

Originally Posted by Shiori-kun To be absolutely honest, apache name based virtual hosts can use different ssl certificates but the pain and complexity to get it to work is quite painful and if it breaks, you will be truely on your own.

I would like to know why you say this.

You can (easily) serve multiple vhosts with separate certificates using the SNI extension to the SSL protocol. It is easy to configure and fully supported by any recent browser and OpenSSL 0.9.8f or later.

That said, I am not sure I understand the OP's problem. If the domain is the same as it apears to be, https://wiki01.xx.yy and https://wiki01.xx.yy/mediawiki1, but the second is redirecting to non-secure protocol I would interpret that to be due to some other server (mis)configuration and neither an SSL or name-based vhost specific problem.

I say sni-based ssl is a pain because we are doing it for a client and it goofs a lot. Because of how ssl sessions are created before the http request, the sni is lost and must be re-requested. If your browser supports this then its not really a problem, but you will not get your ssl green bar all the time. Mobile browsers dont handle this very well and tend to need a gentle push to try again (though they are getting better). If the client browser requests http first and is redirected to https, then all works as it should. Hence it works. The PITA part is if the browser requests https without the ssl session active then it must retry the request after building the ssl session, which doesnt always happen. I have fielded plenty of calls over this behavior, which is easier avoided by using IP based vhosts. Yes, I am painfully aware of the IPv4 issue, but just because your using the ip for http(s) access, doesnt mean you cant also use it for other services.

As for the redirect issue; a browser that does not do proper sni based ssl will generally try standard http looking for a redirect or an index page. Without the redirect on port 80 for that vhost, the server should send the index page of the configured document root. Your redirect code is spot on but mod_redirect must be enabled using command line code: a2enmod redirect
Each site should be its own configuration file in sites-available directory with two vhosts configured in each config file. One for port 80 having a 305 redirect to port 443 and another vhost that enables ssl with the correct ssl cert on port 443


Name based vhosts was to be depreciated but even in apache 2.4.25-3 it still worked properly and doesnt do more than throw a warning into the syslog.

Originally Posted by Shiori-kun I say sni-based ssl is a pain because we are doing it for a client and it goofs a lot.

That has not been my experience at all, but comparison would be beyond the scope of this thread. Thanks for the explanation.

Originally Posted by Shiori-kun Name based vhosts was to be depreciated but even in apache 2.4.25-3 it still worked properly and doesnt do more than throw a warning into the syslog.

I was surprised to see this stated earlier in this thread and looked for an explanation. Name based vhosts have not been deprecated. It was the NameVirtualHost directive which was deprecated and is no longer needed because it is the default behavior and handled automatically since 2.3.11.

But returning to the topic of this thread, I do not believe the OP's problem is either SSL or name based vhost related. I base this on the example they provided where the same domain is delivered secure in one case and redirected to non-secure in another, the difference being not in the domain name but in the path. To me that indicates a configuration problem other than the VirtualHost or SSL configuration, possibly in a Directory or Location directive, or even in a .htaccess file if enabled.

They also state...

Originally Posted by Elim Garak I have already tried various solutions (directory, alias entries, etc.) from the Internet, but no success. Either the sites are shown without ssl or I cannot access the pages at all. .

...but without any specific information about what they have tried. This only tells us that the configuration has been altered, but does not tell us its current state.

I think the OP needs to provide a few more details about their configuration and what is actually happening in order for others here to understand the problem and offer help.

Thank you all for your quick help!

I solved the problem by using "Redirect permanent / https://mydomain.com/" in my ssl.conf.

All pages now working wiht HTTPS in Firefox and IE.

Just something I would also to add to thre thread, although not necessarily directly connected to the topic: I have used and I use name-based virtualhosts for dozens of domains without any issues whatsoever. As long as you know how to configure your reverseproxy/webserver (be it apache, nginx, varnish, whatever), there shouldn't be any problems whatsoever (either for mobile or full-blown browsers).

As far as post #2 is concerned: "If you are sharing a single ip address and name based virtual servers, then you will only be able to use one certificate", this is false.

Of course you can use a single certificate for several domains, although very often you'd use one certificate for one virtual host (but there is no rule to it). If you have a wildcard certificate, you can use it for as many subdomains as you want, but you can also have several different main domains within the same certificate anyhow. They are called multi-domain certificate (e.g. https://www.namecheap.com/security/h...tiple-domains/).

#7 "One for port 80 having a 305 redirect to port 443". I think you're referring to a 301 redirect (can also be 303, depending on what you're trying to get across).