Proper SSL Apache2 Port Config

Hi all. Setting up SSL on a server for the first time, have about 20 virtual sites I run on this site, but just the one is going to be using SSL. Have the proper directives in that individual virtual hosts configuration file and ssl is working fine.

One question I had was on the overall port configuration for the server. I am running apache2 on debian, and here is the configuration I have that is working, but not sure if it's the proper way to do it.

ports.conf

Listen 80
 <ifmodule mod_ssl.c="">Listen 443</ifmodule> 

virtual.conf

NameVirtualHost *:80
NameVirtualHost *:443

sites-available/default

<virtualhost *:80=""></virtualhost>

sites-available/default-ssl

<virtualhost *:443=""></virtualhost>

sample virtual host

<virtualhost *:80=""></virtualhost>

my ssl only virtual host

<virtualhost *:443=""></virtualhost>

Look ok? I guess I am asking, as when I hit a virtual host via https that is indicated as only :80, the server presents me the certificate (which is incorrect for the domain of course). What i'd like to have is the same as happens when someone tries to hit my ssl only vitual host with the :443 via http, which is an apache message saying not found.

Thanks for any pointers,

Paul

7 Replies

It looks pretty good to me. Here are some suggestions.

Only have 1 *:443 site. In that VirtualHost you have the SSL configuration, the SSL on, and the CertFile stuff.

Since a SSL cert is tied to the domain name only have the ServerName set, no need for ServerAlias since it would get an SSL error. I hate when you can access a site thru example.com, but the cert is signed to www.example.com

If you want have the *:80 version Redirect to the HTTPS site.

I can post my SSL config later today, I am doing Apache 2 on Ubuntu so it is the same setup as yours

@kali25:

Since a SSL cert is tied to the domain name only have the ServerName set, no need for ServerAlias since it would get an SSL error. I hate when you can access a site thru example.com, but the cert is signed to www.example.com

Dang. So when I got the cert issued, the site I got it from stated that getting the cert signed for www.example.com meant it would be good for both www and non-www… we are planning on using non-www… is this a technical problem, or just a personal preference?

Thanks for the confirmation. Going to redirect the :80 to :443 now.

An SSL Certificate has 3 things that must be configured correctly otherwise it will produce an error in the browser.

1. The Certs date must be within the day it is used. For example a Cert is issued 1/1/2009 and expired 1/1/2010 would be valid today 10/27/2009. You must install a new cert befroe the old on expires to not get any errors.

2. The Common Name or CN of the Cert MUST match the domain name EXACTLY or an error will be produced. If the cert CN is www.example.com and you access it thru example.com you will get an error. It can only be accessed thru www.example.com. That is why I do the redirect. http://example.com and http://www.example.com both redirect to https://www.example.com. https://example.com is not setup so the user would get a "server not found error" which I think is better then "an invalid cert error" but since people usually don't type http:// or https:// the browser defaults to http:// which you can catch and redirect to https://www.example.com

3. The Cert much be singed by a Certificate Authority Trusted by the webbrowser. If you paid for the cert then you are ok on this one.

Here is a real world example

Go to https://www.bankofamerica.com/

Everything looks fine. The CN is www.bankofamerica.com, the SSL cert is valid for today, and it is singed by VeriSign, who my Browsers trusts. All 3 are good, no errors

Now to go https://bankofamerica.com/

Now I get an error, same website, same cert. But the CN does not match. In Firefox I get this error:

bankofamerica.com uses an invalid security certificate.

The certificate is only valid for www.bankofamerica.com

Date is ok, and singed by is ok, but 1 item is not, the CN is no good, so error we get.

So if they told you that www.example.com would work for non-www, well they are right in regards to the Encryption still works, but the authentication/trust will not, the browser will complain, and in today's world of phishing and stuff if your customers see this they will flee!

Thanks for the run-down. Cert is valid, by one of the big guys, and it can cover up to five domains, so I'll have both www.example.com and example.com as being covered by it.

Thanks for the help,

Paul

@pmmenneg:

it can cover up to five domains

One Cert equals one domain name. So you must be able to get up to five separate certs with what you purchased. Unless there is something I don't know. I have heard of wildcard Certs, but I know nothing about them.

If it is separate Certs then you need to set them up separately, but there is also a 1 Cert to 1 IP restriction, so if you have multiple Certs then you will need to buy more IPs from Linode.

This is getting a little fuzzy for me so I may not be speaking the total truth.

It's a Unified Communications Certificate (UCC) certificate. Essentially, you tell the CA which domains to cover, and it spits out a new single cert that covers all of those. Very handy for a site (like mine) with sub-domains that you want secured as well.

http://help.godaddy.com/article/3908

Very handy, as it essentially solves the 'securing multiple virtual domains on a single IP' problem that some run into.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct