SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Ive been reading a few posts about how to set up SSL on apache. In case you didnt know SSL allows you to have secure encrypted data sent to and from your webserver. If you ever do online banking and notice all the URL's start with https:// and have a lockpad symbol on the browser, well thats SSL.
To setup SSL with the Apache server supplied with Slack10/9.1 is fairly easy but there are a few steps that arn't so intuitive so this faq should have you set up in no time.
In order to tell Apache to include SSL support we need to edit the /etc/apache/httpd.conf file and scroll ALL the way to the bottom. This is where we will uncomment the following line.
Code:
change this:
#Include /etc/apache/mod_ssl.conf
to this:
Include /etc/apache/mod_ssl.conf
Once that is done you need to make a simple edit to the /etc/rc.d/rc.httpd file so that the apache server knows you want to startup with SSL support.
Now all thats left is to setup the SSL Certs. If you really dont care about having offical certs, Slackware comes with pre-made ones, I use these, but if you ran a legit production webserver you would probably want to spend the money and have real certs made. You also have the option to create your own self-signed certs and if you are interested in that, jump all the way to the bottom of this Howto. Anyway, to use the premade certs run the following commands and say yes to overwrite:
Now all thats left to do is restart the apache server:
Code:
/etc/rc.d/rc.httpd restart
If you want to make sure that SSL is working correctly run this command:
Code:
netstat -tpan | grep 443
If everything is working correctly, you should get output that looks like the following:
Code:
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 27426/httpd
If you don't get any output whatsoever then something went wrong and you need to look at your /var/log/apache/error_log file.
Now that SSL is all set up, you are going to want to tell Apache what to serve up when sombody connects using https://. This is done by the VirtualHost directive and the one pertaining to SSL connections can be found in the /etc/apache/mod_ssl.conf file. The default looks like this and you will certainly need to change some of the settings.
Code:
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot "/var/www/htdocs"
ServerName new.host.name
ServerAdmin you@your.address
ErrorLog /var/log/apache/error_log
TransferLog /var/log/apache/access_log
And finally if you want to create your own self-signed certs and not use the ones that come with Slackware thats easy to do as well. I got the following commands from http://www.apache-ssl.org/#FAQ
Code:
Step one - create the key and request:
openssl req -new > new.cert.csr
Step two - remove the passphrase from the key (optional):
openssl rsa -in privkey.pem -out new.cert.key
Step three - convert request into signed cert:
openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days 1825
Step four - copy the cert and key to the appropriate places
cp new.cert.cert /etc/apache/ssl.crt/server.crt
cp new.cert.key /etc/apache/ssl.key/server.key
A few things to note:
When asked for Common Name in step one, be sure to enter the FQDN of your webserver ie www.mywebserver.com
When asked for A challenge password in step one, go ahead and just press enter
If you don't remove the passphrase from the key in Step two, you will be prompted to enter a password everytime you run /etc/rc.d/rc.httpd start. This means if your box reboots for some reason, your webserver wont start unless you are there to provide the passphrase.
Originally posted by SiegeX Now all thats left is to setup the SSL Certs. If you really dont care about having offical certs, Slackware comes with pre-made ones, I use these, but if you ran a legit production webserver you would probably want to spend the money and have real certs made.
And if I'm not mistaken, the certs provided with Slack expire after thirty days. Not sure about this, but the ones that OpenSSL/mod_ssl generates on install from source have this limit.
This isnt meant to be flaimbait, but I hear this "free as in beer" thing all the time, especially on Slashdot. Can you explain the saying to me, cause I dont remember the last time I picked up 12 pack of Corona for free
And thanks for the link, ill go check it out myself.
Not sure of the actual origin of the expression, but it refers to there being no monetary cost for the product/service/etc. It generally is meant to distinguish these 'no-cost' items from GPL'd or other truly free licenses where one is free to modify and re-release the product. In the case of these 'free' certs, I think that's a good thing, since freely modifiable certs wouldn't really certify much of anything, now would they?
But now that you mention it, I haven't had free beer since college. Aaahh, good times :-)
Keep in mind that SSL layer works with IP before httpd can resolve name, so when using SSL with virtual host, you have to work with IP-based virtual hosting (see http://httpd.apache.org/docs/ for infos)
Originally posted by Cedrik Keep in mind that SSL layer works with IP before httpd can resolve name, so when using SSL with virtual host, you have to work with IP-based virtual hosting (see http://httpd.apache.org/docs/ for infos)
That's only true if you want to use SSL with more than one domain name. If you just want SSL with one domain you can still use named virtual hosts. For example, here is a portion of my vhosts.conf.
As you can see, I got around using IP-based virtual hosting by specifying the port number in both the NameVirtualHost and VirtualHost directives. Now if I wanted SSL support for both www.atozcomp.comANDwww.identityflux.com then yes, I would be forced to buy another IP (one for each domain) and use ip-based virtual hosting.
You're very correct, the asterisk * matches all address, but It's still considered name-based virtual hosting because Apache relies on the client sending the HOST directive for it to make the decision on what webpage to serve up. Not to mention that im using the "NameVirtualHost *:80" directive which IP-based obviously doesnt have. And just so you know im not making it up, here is a simple name-based example I got from apache.org, you'll notice it looks remarkably similar to my vhosts.conf file. If you want more clairification have a looksee at:
I said that with SSL virtual hosting in apache is ip-based because from network protocols point of view, the SSL layer is between transport layer (like tcp) and application layer (like apache and bind) some call this layer the session layer.
Given that, how do you think SSL will accept the connection if the connection need apache to resolve host ?
when using SSL with virtual host, you have to work with IP-based virtual hosting
Im not arguing with what layer SSL works on, all I am saying is that the above statement is not true, you can still use name-based as long as you only want to use SSL with one domain. Apache defines IP-based virtual hosting by putting the actual IP (and sometimes the domain) in the <VirtualHost> directive. Using the Asterisk *, even though it matches all ip's is still considered name-based.
In this case you are sure it is name-based, and I am sure it won't work too
Don't take what I say as a critic for your work though, I am sure you know how to manage your server, but for me this ip-based thing was important to understand, I did some error in the past about this so for now I configure ip-based virtual host in each case there is SSL.
...Some reasons why you might consider using IP-based virtual hosting:
...
Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.
"Free as in beer" simply means that Open Source software does not cost any money to acquire, ie, it's similar to someone giving you a free beer at a party. You are getting something of value without any monetary cost.
"Free as in speech" means that everyone has an equal standing and opportunity to participate in Open Source development (if they so choose) and that there are no barriers or restrictions to block someone from participating.
To elaborate on this somewhat, just like in a democracy, where people are free to express their thoughts without limitation, in the context of software development people are free to add their own contributions to the code without limitation. Futhermore, just as good ideas will florish and poor ideas with wither away, good code will florish and become widely adopted, while poor code will fade away.
Thus, Linux (and OSS) is both "free as in beer" and "free as in speech" -- it costs nothing to acquire, and you can use it without restriction. This may not be the best description of the difference, but FWIW it works for me. -- J.W.
I think you just have your terms mixed up. As far as apache is concerned, the difference between name-based and IP-based is whether or not apache relies on the client to tell it what hostname to serve up. The directive that takes care of this is NameVirtualHost. In my vhost.conf you'll notice I use the NameVirtualHost directive and thus apache does require help from the client thus making it name-based.
In contrast to the code above with no NameVirtualHost and the domain instead of a *, Apache doesnt care what the client says because presumably www.baygroup.com and www.smallco.com resolve to differnt IP's but are bound to the same interface.
And by the way, I have changed my vhost directive to <VirtualHost www.identityflux.com:443> and it works just fine, you can test it out yourself https://www.identityflux.com. And the reason why it works is because I only have one domain that needs SSL. Now if I were to add another vhost below my current one in mod_ssl.conf that looked like <VirtualHost www.atozcomp.com:443> then I would be up a creek because im trying to use SSL with two differnt domains but only one ip, which is why apache suggests ip-based for SSL. In actuality what happens in this case is that the vhost that is listed first is the one that will always get served up; which is identityflux.com in my example.
By the way I dont take any of this personally nor should you, I just don't think you're right
I saw the exemples in apache.org but for me, that will not change my thought nor my httpd configuration methods anyway, that is the result wich is important isn't it (the server will work)
I explain my point of view from network protocols : a web client send the HTTP request, this request (in a tcp frame) go through IP (network layer), then TCP (transport layer), then it go through session layer where it meets SSL handshake (= the browser accepts the secure Web server's certificate) but BEFORE the HTTP (application layer) request which identifies the appropriate name based virtual host.
So it can not work for named based virtual host because in this case the SSL handshake has no way to know which virtual host has the certificate.
I works in your case because Apache listen on port TCP 443 (so at the transport layer) and just for one virtual host (so just one IP, network layer), so the adress is already resolved at the transport layer BEFORE SSL (session layer) send the certificate.
To clarify, I can say you do port-based virtual hosting (although the term does not exist). The port is in transport layer so it is before the session layer (SSL).
Also when you said hen I would be up a creek because im trying to use SSL with two differnt domains but only one ip...
This is not true, you can have two different domain for SSL Vhost if you change port number like :
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.