Solved

SSL port configuration - How to listen on additional port to 443?

Posted on 2011-02-14
7
1,084 Views
Last Modified: 2012-05-11
I wish to set an apache server that is running on Novell OES2 to listen on ports 443 and 444 for SSL.
Is this possible and if so how do I best achieve this given my original config below?

The default listen.conf shows this:
Listen 80
<IfDefine SSL>
    <IfDefine !NOSSL>
	<IfModule mod_ssl.c>

	    Listen 443
	    Listen 444  <<< This is what I added but it didn't work.
	</IfModule>
    </IfDefine>
</IfDefine>

Open in new window


I don't quite understand the above section's logic.
'If SSL', then 'if NOT SSL' means to me that the directive to listen on SSL port 443 (and my additional 444) will never happen.  But 443 is accessible, though 444 is not.

An example I found on the internet looked much simpler like this:
<IfDefine SSL>
Port 80
Port 443
</IfDefine>

Open in new window





0
Comment
Question by:blokeman
  • 4
  • 3
7 Comments
 
LVL 50

Expert Comment

by:Steve Bink
ID: 34893921
The Listen directives are fine, but you also need to set up the host entries to turn the SSL engine on.  For example:

Listen 443
Listen 444
<VirtualHost 1.2.3.4:443>
  ServerName myhost.com
  SSLEngine On
  # other SSL related directives here
</VirtualHost>
<VirtualHost 1.2.3.4:444>
  ServerName myotherhost.com
  SSLEngine On
  # other SSL related directives here
</VirtualHost>

Open in new window

0
 

Author Comment

by:blokeman
ID: 34903883
You may be on to something there!
I am a linux admin so apache is out of my sphere...What is the name of the file that you added these host entries.
0
 
LVL 50

Expert Comment

by:Steve Bink
ID: 34903960
It can be any file, so long as it is included somewhere in your conf chain.  I normally put virtual host definitions in their own file separated by site for better management.  If you look inside your main httpd.conf (or maybe it is apache.conf), you should see where this is already set up.  
0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 

Author Comment

by:blokeman
ID: 34960043
Just looking at this again...
Routinet:
I noticed in your example that it has Listen 443

Should I need to include this "Listen 443" in a virtual hosts file if the server is already working with SSL on 443?
The extra bit I want to achieve is SSL on 444 (in addition to 443), so I thought that a virtual host definition should only need 444 mentioned.
0
 
LVL 50

Expert Comment

by:Steve Bink
ID: 34961123
It does not matter if the Listen directive is in the main conf file or an include.  It should be in the top (server) scope, so just make sure it is outside of any <VirtualHost>, <Directory>, or other container you create.
0
 

Author Comment

by:blokeman
ID: 34977214
I want to keep things as simple and consistent as possible, so I checked /etc/apache/httpd.conf which listed:
Include /etc/apache2/vhosts.d/*.conf
Looking in that include path I found:
vhost-ssl.conf

In that conf file I found:
<VirtualHost _default_:443>

        #  General setup for the virtual host
        DocumentRoot "/srv/www/htdocs"
        #ServerName www.example.com:443
        #ServerAdmin webmaster@example.com
        ErrorLog /var/log/apache2/error_log
        TransferLog /var/log/apache2/access_log
        # other SSL related directives here
</VirtualHost>  

So should I simply just copy the complete <VirtualHost _default_:443> directive to a new directive called <VirtualHost _default_:444>?
Or would I be best to create new log file locations for port 444?

I noticed in your example you have the ServerName directive in use, but my existing <VirtualHost _default_:443> does not include a ServerName directive - does this matter at all?
0
 
LVL 50

Accepted Solution

by:
Steve Bink earned 500 total points
ID: 34977821
A lot of your questions are left up to personal preference.  You'll find your own strategy once you have more experience managing the server.

My own preference is to keep each vhost in its own file.  In my main conf, I have:

Include /etc/apache2/sites-enabled/*.conf

Open in new window


My actual vhost conf files are in /etc/apache2/sites-available, with only links in the sites-enabled directory.  If I want to disable a site, I can just delete the link, leaving the physical conf file untouched.  Having each of my vhosts in a separate file means I can do this without editing any file, which is huge bonus once you have 20-30 sites on a server.  

As far as your own vhost container, you can certainly start with a copy of the default host, but I highly recommend customizing it to your uses.  Go through the directives that are there and make sure they apply to your site as you think they should.  For example, maybe you want access/error logs to go to a specific file, not the general one used by the default site.  You probably want a different DocumentRoot location.  

The reason the default vhost does not use ServerName is because it is the default - it is supposed to respond to any requests not picked up by other vhosts.  You should supply a ServerName directive, and possibly ServerAlias directives, for each of your vhosts to limit their responsiveness.  If you want a particular site to be the default, it is OK to leave those out, but do remember to disable the built-in default site you have already found.  Remember that Apache matches the vhost by first matching definition, and the definitions are ordered by the order of their inclusion.  So, if you create a file called avhost.conf, it will be included before vhost.conf, while whost.conf will be included after it.

I highly recommend looking through some of the Apache documentation for how the conf file system works.  A little bit of reading can provide an enormous amount of enlightenment.  http://httpd.apache.org/docs/2.2/
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

In my time as an SEO for the last 2 years and in the questions I have assisted with on here I have always seen the need to redirect from non-www urls to their www versions. For instance redirecting http://domain.com (http://domain.com) to http…
It is possible to boost certain documents at query time in Solr. Query time boosting can be a powerful resource for finding the most relevant and "best" content. Of course the more information you index, the more fields you will be able to use for y…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
When you create an app prototype with Adobe XD, you can insert system screens -- sharing or Control Center, for example -- with just a few clicks. This video shows you how. You can take the full course on Experts Exchange at http://bit.ly/XDcourse.

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now