In the protocol stack used in the internet. The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP or IMAP.

The SSL protocol includes two sub-protocols:
1) SSL record protocol
2) SSL handshake protocol

The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection.

Now SSL for the layman
SSL basically creates an encrypted communication channel between the two parties involved in the communication. For a third person involved in the middle of this communication channel, the data seems to be garbled.

Suppose Alice (A, the browser) wishes to communicate with Bob (B, the server) then the exact steps that takes place inorder to begin the encrypted communication are:

1) A -> B hello
Alice contacts Bob and requests for a private communication (request for an https link at port 443)

2) B -> A Hi, I’m Bob, bobs-certificate
Bob send back to Alice his certificate. A certificate authenticates that it is Bob who is actually communicating with Alice. It is like a unique ID card displayed.

3) A -> B prove it
Alice requests Bob to prove his identity.

4) B -> A Alice, This Is bob { digest[Alice, This Is Bob] } bobs-private-key
Bob sends back a message and its digest encrypted with his private key. This step can also be like sending a document with a digital signature (when you have Alice’s public key).

5) A -> B ok bob, here is a secret {secret} bobs-public-key
Alice sends back to Bob some secret. Usually a session key encrypted using Bob’s public key obtained from his certificate

6) B -> A {some message,MAC}secret-key
Next Bob generates a secret key from Alice’s secret (earlier step) and sends back to Alice the real message and its MAC encrypted with this secret key. This is actually the encrypted website.

Terminologies

Certificate
This is actually bobs public key containing document which is digitally signed by a certificate issuer’s private key (like Verisign). In this process Verisign gets all the necessary documents to verify that Bob’s identity is correct and it gets Bob’s public key (and some other data like certificate expiry period, Bobs identity) and encrypts it with its own private key. Now Verisign’s public key comes built-in along with every browser (so that the browser can get bobs public key from within it).

Digest
Digest or more appropriately Message Digest is like a summary of the actual message or a portion of the message. The digest of a message is is unique for every unique message, it is a one way function such that obtaining the digest, it is never possible to recover the original message (This does not involve using any key in the process). Message Digest always appears with the original message. Upon reception of this Message and its digest at the receiver’s end, the receiver can once again calculate the digest from the original message and verify the integrity of the message.

Digital signature
Let Bob send a document to Alice which is digitally signed. For this Bob must have Alice’s public key and Alice must have Bob’s public key.Bob takes the document, encrypts it first with Alice’s public key and next with its own private key(Bob’s)

B -> A [{message}alices-public-key ]bobs-public-key

Session Key
The only secret which is communicated using public key encryption is a session key. Now the session key is chosen from the ’secret’ that the parties accept. the session key could be the secret itself or a portion of the secret or the result when the secret is passed through a previously agreed algorithm. The SSL encrypted communication does’t necessary have to be created using a public key encryption technique (This uses a lot of overhead, i.e. processing and time), it may be simple symmetric cypher(less overhead) using this session key once agreed upon. There are a variety of cypher suites available (IDEA Blow-fish RSA DES MD5 KEA) and both the parties may choose some encryption technique based on the protocol used (SSL1.0 SSL2.0 TLS etc)

MAC
MAC or Message Authentication Code is similar to the Message Digest we have discussed. It is used to verify the integrity of the Message.

MAC := Digest[ some message, secret ]

Files associated with SSL

CSR
CSR or Certificate Signing Request is a string of text generated by the server. This file is sent to the SSL vendor while purchasing an SSL. In the process of generating your CSR, you provide a number of details regarding the domain being registered. Excerpts of text from all these are taken to generate your private key. This private key is present only within the server and nowhere else. The content of the CSR basically contains the public key along with all the details you have used. You get this as domain.com.csr or domain_com.csr.

CA bundle
CA (Certificate Authority) bundle file is one which contains the public key of the Certificate Issuer (Like Verisign’s public key). Usually this is not required while installing the SSL and most browsers will have this detail in advance to decrypt the SSL certificate (the CRT file) from the server. You get this as domain.com.cabundle or domain_com.ca-bundle.

CRT
This is the actuall SSL certificate as obtained from the SSL vendor. It is a file (containing the public key of the domain secured with SSL and other details like the expiry date, owner information, address etc of the SSL) which is encrypted with the private key of the SSL vendor (Digitaly signed by the SSL vendor). You get this as domain.com.crt or domain_com.crt .

Key file
This is the file which holds your private key (strictly confidential material). The file will have the RSA private key as generated by your server software. You get this as customcardsplus.com.key or customcardsplus_com.key. This file is not usually send to your SSL vendor unlike the CSR. You get this as domain.com.key or domain_com.key .

SSL in a cPanel server
Any service can be secured in a communication channel which is encrypted with SSL. Each of this service on the encrypted channel will be on a different port. Some of them are as follows:

A domain served as a secure webpage will require a dedicated IP (in a shared environment). SSL protocol is designed to use IP-based mapping. SSL does not support host headers. Therefore, you should have a unique IP address assigned to your secure site. These pages are served from the port 443. Let us examine the configuration of such a website in the apache’s config file /usr/local/apache/conf/httpd.conf.

Every website (in our example domain.com with username: doma) enabled with SSL has a unique set of directives in the VirtualHost section for the 443 port as:

<VirtualHost 266.11.208.293:443\> Dedicated IP of the domain

ServerName domain.com #Domain name secured with SSL
ServerAlias www.domain.com

DocumentRoot /home/doma/public_html

ServerAdmin webmaster@domain.com
UseCanonicalName off
CustomLog /usr/local/apache/domlogs/domain.com combined

CustomLog /usr/local/apache/domlogs/domain.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."
ScriptAlias /cgi-bin/ /home/doma/public_html/cgi-bin/
SSLEngine on #This directive enables the SSL on this domain
SSLCertificateFile /etc/ssl/certs/www.domain.com.crt #Location of CRT file
SSLCertificateKeyFile /etc/ssl/private/www.doma.com.key #Location of Private key
SSLCACertificateFile /etc/ssl/certs/www.domain.com.cabundle #Location of CAbundle file
CustomLog /usr/local/apache/domlogs/domain.com-ssl_log combined #Log specific for the SSL served webpage
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

<Directory "/home/doma/public_html/cgi-bin">
SSLOptions +StdEnvVars #This directive will pass mod_ssl environment variables to the server scripts.
</Directory>

</VirtualHost>

Some times the directive SSLCertificateChainFile is used in place of SSLCACertificateFile. The minimal addition you will have to make to enable SSL in your httpd.conf file is:

<VirtualHost 192.168.0.1:443>
DocumentRoot /var/www/html
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>

There are two locations where you are likely to find the SSL related files in your cPanel server. Usually the crt, key and the ca bundle are present in the home directory of the user in /home/username/ssl/, if it was installed using the client’s cpanel. However if the WHM was used instead to install the same, you will find it in /etc/ssl/. In either of these locations you will find two directories: certs/ and private/. certs contain the crt and cabundle while the private contains the keys.

Now you know how ssl works in your server, Any more questions? just comment!

Tweet This Post

Like in the case of all apache modules, you can either compile PHP as a static module or compile it as a dynamic module.  In the case of static module , you  can’t perform any modification for the module without recompiling the binary to which it is attached.  For eg.  you can’t add ssl support for the mod_php without re-compiling apache as a whole. And any failure in the compilation may cause downtime for the entire webserver also, including plain html support.

The advantage is that it provides a faster  performance, because the module is initialized  whenever the apache binary is started.

In the case of a dynamic mod_php installation, the necessary modifications or module additions can be done by recompiling the module alone. There is no need to recompile the Apache as the mod_php is not linked with the binary of apache.  But since the webserver loads the module on the fly, it needs to load, initialize and then execute the module.  So it can create some level of slowness while processing php pages.

How does mod_php work?

When PHP  is loaded into Apache as a module (using mod_php), each Apache process will contain an instance of mod_php or PHP interpreter also.   The interpreter comes with a bundle of libraries we enabled during compilation and each  process can make use of these libraries to process the requests. This means that the Apache process that just started  to load a simple HTML page  too will contain a PHP interpreter with all assigned libraries which inturn means resource consumption.

When the webserver gets an HTTP request. The  request header  contains the path to the requested document

e.g. access.log:    xx.xx.xx.xx – - [22/June/2010:21:14:53 -0700] “GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1″ 200 2146 “http://domain.com/info.php” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7″

1. The request will be redirected to the document root of the domain and then to the file “info.php” , if it fails then the corresponding error message will be given.

2. The info.php file is to be processed. It follows the following steps

Normally every httpd.conf file will have an entry like this

AddType application/x-httpd-php .php5 .php4 .php

It instructs the webserver that the files with extension .php ,.php4,.ph5 are of PHP mime type . The TypesConfig directive sets the location of the MIME types configuration file. This file controls what Internet media types are sent to the client for  given file extension(s).  Sending the correct media type to the client  is important so they know how to handle the content of the file.

root@new [/usr/local/apache/conf]# cat mime.types | grep x-httpd-php
application/x-httpd-php-source          phps
application/x-httpd-php          php php3 php4 php5 php6
root@new [/usr/local/apache/conf]#

Here we can see that the Mime type to be used for files with extension .php  is application/x-httpd-php , while the file with .phps is to be mapped to the php mime type application/x-httpd-php-source .

The webserver identifies that the requested file is of Mime type x-httpd-php.

To handle or process it , the apache has to load the corresponding module. Since it is a php type , the module mod_php will be loaded and it will execute the file.

Since apache is a HTTP server. It gets the HTTP requests and answers with the HTML code.  So the mod_php will execute the commands within php flag and creates the HTML page dynamically and send it back to the client – internet browser which sent HTTP request.

Security concerns / Implications

You can see that  every request or execution of a php file through web is initiated by the webserver. So the webserver acts as the parent of every php execution through web. It imposes a great security threat. Since apache is being executed as an apache  user, all process will be owned by that user. By default  it is “nobody” or “apache”.  Let me try to explain.

If your  web application performs some operations in the db, unless that database (eg: a flat text DB) has built-in access control, you will have to make the database accessible to the “nobody” user. This means a malicious script could access and modify the database, even without a username and password.  Such can be the case with various configuration files too.  Unless you protect these directories or applications with necessary authorization techniques like .htaccess, session control etc. There is a high possibility of attack through webapplication.

Another dangerous issue is of root escalation. If the webserver has a bug, by exploiting that bug, a malicious user can gain some root privileges or escalated to root. Its quite alarming situation as an escalated apache user can do any sort of  actions without any level of authentication.

Also it is difficult to identify the script which performs the malicious activity as all php scripts will be executed as “nobody”

Since PHP applications are executed as web server user, you need to give access and write permissions for the directories wherever the application  is supposed to be working. Sometimes you may be forced to give 777 permissions and it invites lot of attacks.

The files created by php applications will be owned by user “nobody” . So the user will not be able to delete the files unless it is done through another php application. Otherwise he needs to contact the server admin to get the same.

As a security measure, we may be forced to block mails from “nobody” users . But it can create mails generated from php applications being blocked in the server. Various php applications widely used for spamming . So some servers are configured to block mails from nobody users. This creates inconvenience to users.

Tweet This Post

PHP is similar to many other scripting languages like perl, python etc. But unlike perl and python what makes it stand apart is, its adaptability and power to be used as both command line and server side scripting.  I hear Yahoo’s mail runs on PHP.

I shall try to explain you the difference by executing the same file on different modes. Don’t expect too much from this post.

Command Line (CLI)

PHP Command Line Interface or PHP CLI  as the name implies,  is a way of using PHP in the system command line, like below.

# php -i | more
phpinfo()
PHP Version => 5.2.10-2ubuntu6.3

System => Linux den 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 200
9 i686
Build Date => Nov 26 2009 14:40:20
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini

In other words when the SAPI ( Server API) is “Command Line Interface” as you see above php-cli acts as a connector between underlying  php binary and the command / script which invokes php from shell . This enables processing of the scripts which require php functions and provide the result after execution of the script.   The advantage is that it doesn’t require a browser or webserver  for the execution. It simply requires a PHP parser ie PHP_CLI. This type of usage is ideal for scripts regularly executed using cron (on *nix or Linux) or Task Scheduler (on Windows). These scripts can also be used for simple text processing tasks. (Okay even image processing tasks )

PHP CLI is available on all popular operating systems.  The first step we need to ensure is that the CLI SAPI is installed. For this locate php binary path and execute the command as given below

[george@server3]$ type php
php is /usr/local/bin/php
[george@server3]$ /usr/local/bin/php -v | grep cli
PHP 5.2.9 (cli) (built: Jul 10 2009 19:22:08)

The result ensures that the php-cli module is installed. Now let us  see, how to make it work in a shell. The first thing is to identify the exact path on which php  binary is present. I assume that its /usr/local/bin/php.

Now create the test file info.php

vi info.php

<?php
phpinfo();
?>

Execute the  file from the shell using the command line or shell. If you intent to use it in a cron specify the binary path (interpreter) as the first entry of file .

/usr/local/bin/php info.php

Then the out put will be  of the following  format

[geroge@server3]# php info.php | head
phpinfo()
PHP Version => 5.2.9

System => Linux server3.xxxxxx.xxx 2.6.18-128.7.1.el5 #1 SMP Mon  Aug 24 08:21:56 EDT 2009 x86_64
Build Date => Jul 10 2009 19:17:35
Configure Command =>  './configure'  '--enable-bcmath'  '--enable-calendar' '--enable-dbase' '--enable-ftp'  '--enable-gd-native-ttf' '--enable-libxml' '--enable-magic-quotes'  '--enable-mbstring' '--enable-pdo=shared' '--enable-soap'  '--enable-sockets' '--enable-zend-multibyte' '--enable-zip'  '--prefix=/usr/local' '--with-curl=/opt/curlssl/'  '--with-tidy=/opt/tidy/' '--with-ttf' '--with-xmlrpc'  '--with-xpm-dir=/usr' '--with-zlib' '--with-zlib-dir=/usr'  '--with-litespeed'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => /usr/local/lib/php.ini

You can see the Application Programming Interface (API) for this script by  checking the variable Server API. In the above test, it is shown as Command Line Interface. The value gets changed according to the mode of usage or execution.

As I mentioned above the php binary was  invoked  by the php-cli interpreter. Once php binary executed the query , the result was returned to the SAPI  ie php-cli, it then passed the results to the command line.

Why do we use it?

Its a quite handy option to create cron jobs. Some times we may need to perform some sort of updates or script execution periodically. If we set  a cron job for this using php, the php-cli option is quite useful.

Server-side scripting

PHP is extensively used for creating dynamic Web pages. You create pages with PHP and HTML. When a visitor opens the page, the server processes the PHP commands and then sends the results to the visitor’s browser along with the static HTML pages. PHP code is embedded into the HTML source document and interpreted by a web server with a PHP processor module, which generates the web page document.

So the minimum requirement for here are the following ones

1.  Web browser ( client side)

2.  Web server

3.   The PHP parser :  which connects the webserver with the underlying php installation.

Illustration :

Now lets us, take the same example. Here I am trying to access the page through a web browser. Let us see how the result looks like

Here , you can see the difference. In the first case when I executed the same file from shell  I got the output without any format. Now the same result is shown as an HTML page.  So let us see  how the conversion takes pace.

The webserver is  connected to the php with the help of “Server API” . This is called PHP parser  it is either CGI or Server Module like apache, litespeed etc. You can see  it is “CGI” here, but it can vary according the mod of installation and webserver it uses. Common values are FastCGI/CGI , Litespeed API, Apache etc

Once the HTTP  / Web server gets the request for the page with php , it calls PHP interpreter to generate HTML. Then this HTML is returned to the client – internet browser which sent the HTTP request.

I believe you might got some ideas how it works or differs . I shall try to give  the difference between CGI and a server module on another post

Server API (SAPI)

PHP is meant  to work on all platforms. So it is essential that it should work with different types of webservers as well.   Every version of  php comes with a set of Binaries to connect php with various webservers and it is known as SAPI.  During configuration of php, we  need to give corresponding options for the webserver to which the interpreter is to be enabled. Once the php is compiled and installed , the corresponding SAPI  will be activated. So every communication between the webserver and PHP will be interpreted  using the corresponding SAPI module enabled.

Apache may use “Apache Handler” while LiteSpeed webserver use “LiteSpeed API” as the SAPI.

Extensions

Being a powerful language which can perform various levels of operation,  PHP needs to utilize various functions and libraries installed on the server. For example GD libraries are required for a php script which performs image manipulations. While a shopping cart or such applications require db connectivity to be enabled.  Like in the case of SAPI a lot of such connectors are shipped along with PHP.  To extend the functionality of php, we enable the necessary libraries while configuring the application using “–with”  option.

You can create your own php extensions and php modules and compile them also.  Again, we will have a discussion about it later.

Tweet This Post

Here we are going to install apache using the source only. The choice of Operating System here is Linux (distro: Centos). The procedure we follow here will lead to a simple apache installation for dynamic loading of php. PHP will be installed as a module to apache. With a little bit of patience and time, all the necessary modules can be installed with apache. I will be giving a brief idea about the installation of the other modules later.
The basics of installation from the source involves mainly three simple steps (assuming you are lucky):

./configure
make
make install

./configure creates the MAKEFILE on the fly. We can provide the necessary options to configure. To list the available options in the configuring step use

./configure --help

–prefix=/path/… mentions where the executable and its files are installed. If not mentioned it takes the default values.
–enable-[Feature] will enable the specified Feature in apache as it is being built. We are only interested in the DSO capability and hence we enable it with: –enable-so

As a convention we always keep the source code tar ball inside a directory in /usr/src/, thus source installation begins in this directory.

Apache Compilation

Download the required source tar ball of the apache you would like to compile. Here I am installing httpd-2.0.63 from http://httpd.apache.org/download.cgi#apache20. I save it in the /usr/src/ folder.

cd /usr/src/
wget http://www.bizdirusa.com/mirrors/apache/httpd/httpd-2.0.63.tar.gz

This will result in the generation of the file httpd-2.0.63.tar.gz

tar -xzf httpd-2.0.63.tar.gz

This will result in the creation of the directory httpd-2.0.63. Next enter inside this directory and execute the ./configure command.

cd httpd-2.0.63
./configure --prefix=/usr/local/webserver --enable-so

We are installing apache inside /usr/local/webserver and enable DSO to run php as a module to apache. During this process we may get a lot of errors. We resolve these by manually installing the unresolved dependencies either by obtaining their rpms or by using yum. Normally the first dependency we will get to resolve are:

gcc
glibc
libxml and
their corresponding devel packages

In the days where there were no package management tools like yum, pirut, apt-get etc. The old rpms served the installation of these packages with some effort. The task of determining the required rpm package for the required architecture and resolving the other dependencies which arise due to the installation of this rpm may be a tedious task. Some sites which helped in obtaining the necessary rpm suited for our installation and its other dependancies are:

http://rpm.pbone.net/

http://www.rpmfind.net/linux/RPM/

http://ftp.freshrpms.net/

http://dries.ulyssis.org/rpm/packages.html

http://apt.sw.be/

http://rpms.famillecollet.com/ (Remi RPM Repository)

Once everything goes well (we do the ./configure step again to determine this), the make command is executed.

make

If errors are encountered in this stage, We resolve them by installing the unresolved dependencies (Same as the previous step) and then do:

make clean

After this we repeat the make command and then issue:

make install

This process installs the package finally within the system. Modify the init script ( /etc/rc.d/init.d/httpd or /etc/init.d/httpd they are symbolic links) Or sometimes you may even have to create one from the apache site.

The following is the content of one such init script I have used. The line beginning with apachectl/some/path/here and httpd=/some/path/here have to replaced with the appropriate line we have used in the –prefix portion of ./configure.

#!/bin/bash
#
# Startup script for the Apache Web Server
#
# chkconfig: - 85 15
# description: Apache is a World Wide Web server.  It is used to serve \
#              HTML files and CGI.
# processname: httpd
# processname: httpd
# pidfile: /usr/local/apache2/logs/httpd.pid
# config: /usr/local/apache2/conf/httpd.conf
# Source function library.
. /etc/rc.d/init.d/functions
if [ -f /etc/sysconfig/httpd ]; then
. /etc/sysconfig/httpd
fi
# This will prevent initlog from swallowing up a pass-phrase prompt if
# mod_ssl needs a pass-phrase from the user.
INITLOG_ARGS=""
# Path to the apachectl script, server binary, and short-form for messages.
apachectl=/usr/local/webserver/bin/apachectl
httpd=/usr/local/webserver/bin/httpd
pid=$httpd/logs/httpd.pid
prog=httpd
RETVAL=0
# The semantics of these two functions differ from the way apachectl does
# things -- attempting to start while running is a failure, and shutdown
# when not running is also a failure.  So we just do it the way init scripts
# are expected to behave here.
start() {
echo -n $"Starting $prog: "
daemon $httpd $OPTIONS
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/httpd
return $RETVAL
}
stop() {
echo -n $"Stopping $prog: "
killproc $httpd
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f /var/lock/subsys/httpd $pid
}
reload() {
echo -n $"Reloading $prog: "
killproc $httpd -HUP
RETVAL=$?
echo
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status $httpd
RETVAL=$?
;;
restart)
stop
start
;;
condrestart)
if [ -f $pid ] ; then
stop
start
fi
;;
reload)
reload
;;
graceful|help|configtest|fullstatus)
$apachectl $@
RETVAL=$?
;;
*)
echo $"Usage: $prog {start|stop|restart|condrestart|reload|status"
echo $"|fullstatus|graceful|help|configtest}"
exit 1
esac
exit $RETVAL

Next we add the daemon name to the list of services and run it. For this follow the below steps.

chkconfig --add httpd
chkconfig --level 2345 httpd on
chkconfig --list httpd
/etc/init.d/httpd start
lynx http://localhost/ will display the default apache page which means success.

PHP Compilation
Now we are going to install PHP 5.2.13 from source!
Go to /usr/src/

cd /usr/src/

Download the PHP source tarball and extract it

wget http://in3.php.net/get/php-5.2.13.tar.gz/from/in.php.net/mirror
tar -xzf php*
cd php*

Just like in the previous apache installation, we are going to do the ./configure step with the required setting which are displayed using

./configure --help

We are only interested in enabling php as a module (–with-apxs2) support for mysql (–with-mysql) and prefix line. So we go for:

./configure --with-apxs2=/usr/local/webserver/bin/apxs --with-mysql --prefix=/usr/local/webserver/php

The long command can be written in a shorter, more clearer format with:

./configure --with-apxs2=/usr/local/webserver/bin/apxs \
--with-mysql \
--prefix=/usr/local/webserver/php

The same instructions go for the errors here.
Once everything goes smooth:

make
make install

We can provide the recommeneded php.ini setting in the path /usr/local/webserver/php/lib (what ever is the –prefix + /lib) or just copy the recommended settings to /usr/local/webserver/php/lib (This file may have the name php.ini-recommended or php.ini-production)
cp php.ini-recommended /usr/local/webserver/php/lib/php.ini

From now on we can have php’s index page to be the default index page. For this in the apache’s config file append index.php to the directive – DirectoryIndex

The line would thus look like:

DirectoryIndex index.html index.html.var index.php

To make make apache call modular php to execute the php script when encountered, add the following lines to the conf file.

AddType application/x-httpd-php .php
DirectoryIndex index.html index.html.var index.php

Next to test your installation.
In the default document root, create a phpinfo file with the file name index.php an d the contents as:

<?
phpinfo();
?>

Now we will test the apache configuration for any syntax errors and then reload the apache webserver:

apachectl configtest (No errors should be reported)
/etc/init.d/httpd reload

Open a browser window and load the localhost as URL, we will be viewing the phpinfo page in here. In the phpinfo page, the portion Configure Command shows the actual compilation time options used while ./configure is used. The row corresponding to Server API mentions how the php is loaded. ‘Apache 2.0 Handler’ means that php was loaded as a module of apache. The rest of the values can be globally changed by making the required changes in php.ini or locally in .htaccess (which is possible only because it is loaded as an apache module).

Tips on installing PHP as a CGI

Here we do not require installing apache with the –enable-so option. A normal installation will do. The installation of php will not require the option –with-apxs2. However we will have to mention the location of apache source directory with –with-apache=../apache_1.3.14

In the httpd.conf file you will require adding:

ScriptAlias /php/ [path where your php folder is located]
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .phtml
Action application/x-httpd-php /php/php5

Tweet This Post

Here you may see the name of the root server to the left hand side and its IP to it’s right. The list I have put here has the severs up to D only. This list continues till M ( M.ROOT-SERVERS.NET.) .

The IP of these root servers do not change frequently but it does, once in while. Thus no one cares to update this file. So it is advisable to update this file for anyone running a busy NS. You can easily fetch this file with a dig utility:

dig @a.root-servers.net . ns > root.hints

or

dig @a.root-servers.net . ns > named.ca

You can easily set-up a crontab entry to perform file update once in month.

What makes Root Servers so special than other servers?

The key file that makes root servers so special is ‘root.zone’. This is contained in all the root severs from A – M. You can download this file too and view it ! Just note the screen shot in the above page. Two ftp servers are mentioned in the top : FTP.INTERNIC.NET & RS.INTERNIC.NET . Just do an ‘anonymous’ ftp to the above server and get the file by navigating to the specified directory. I have attached a screen shot of a part of it below.

In the two screen shots, we can observe the name of the Authoritative NS for the gTLD ‘.com’ and ccTLD ‘.in’ . These Authoritative NS for ‘.com’ and ‘.in’ will have the IP of Authoritative NS for the domains ( second level or third level ) under it. Similarly all the existing ccTLDs and gTLDs have an entry for their NS in this file.

Now you might wonder: Only the names of the authoritative servers are mentioned here and where to get the IP of these? You need not worry. The IPs are mentioned in the same file after listing NS for all the TLDs. To make things clear I have put a screen print below:

The above is an entry in the same file ( root.zone). A.GTLD-SERVERS.NET. is an Authoritative NS for .com TLD. It’s IPv4 and Ipv6 addresses are mentioned. Similarly, there will be an IP entry for all the all the authoritative name servers for all the TLDs.

Please Note: I recommend the reader to compare the above informations with PART III of this article. It will help in clear understanding.

Okay. Then who updates this root.zone file?

In 2004, ICANN took over responsibility for the maintenance of the root- servers TLD master file—the file that lists the authoritative servers for each TLD. Distribution of this file to each of the operational root-servers is carried out using secure transactions. To further increase the security, the server providing the root updates is only accessible from the operational root-servers. It is not a publicly visible server.

Tweet This Post

The assignment of identifiers such as addresses and names, to ensure that they are created and allocated in a way that is acceptable to all is the main factor for the success of the Internet. So some sort of centralized organization is required. The organization originally responsible for this task was Internet Assigned Names and Numbers (IANA). IANA was originally charged with the task of managing which IP address blocks had been assigned to different companies and groups, and maintaining periodically-published lists of Internet parameters such as TCP and UDP Port Numbers. It also was in charge of DNS registrations. As the Internet grew, there was the requirement of a additional authority to manage the growing load. So by the mid 90s the Internet Corporation for Assigned names and Numbers (ICANN) came into existence.

ICANN is now officially in charge of all of the centralized registration tasks including IP address assignment, DNS domain name assignment, and protocol parameters management.

This development would have meant that IANA would have been completely replaced by ICAAN. But that did not happen. Instead, IANA was put under ICANN and is now in charge of IANA. Both organizations are responsible for IP addresses and parameters. Thus there are basically no differences between the two. These two together are at the top level of the Internet’s Name and Addresses registration and their delegation process. They also maintain the 13 root servers in the world which are at the top of the DNS tree.

For the functioning of the whole DNS system, 2 factors are to be maintained :

1. NAMES (Domain Names)

2. NUMBERS ( IP & TCP-UDP protocol numbers)

NAMES or DOMAIN NAME SYSTEM (DNS)

The domains at their top level are classified as :

1. gTLD (generic Top Level Domain)
2. ccTLD (country code Top Level Domain)

Generic Top Level Domian (gTLD)

The initial gTLDs and their original intended organization types were:

.ARPA : A temporary domain used many years ago for transition from hosts (flat file) to DNS. Its name refers to the ARPAnet, the precursor of the modern Internet. Today this domain is used for reverse DNS resolution.

.COM : Corporations and businesses.

.EDU : Universities and other educational organizations.

.GOV : Government agencies.

.MIL : Military organizations.

.NET : Organizations that implement, deal with or manage networking technologies

.ORG : Other organizations that don’t fit into any of the classifications above.

The .ARPA domain is the “Address and Routing Parameter Area” domain and is designated to be used exclusively for Internet-infrastructure purposes. ( Refer: http://encyclopedia.thefreedictionary.com/Address+and+Routing+Parameter+Area ) It is administered by the IANA in cooperation with the Internet technical community under the guidance of the Internet Architecture Board.The .arpa domain currently includes the following second-level domains: ARPA, IN-ADDR.ARPA, IN-ADDR.ARPA, IRIS.ARPA, IP6.ARPA, URI.ARPA, URN.ARPA . So the ARPA domain was not for commercial registration purposes. This left only six categories for all other organizations. Also, the TLDs weren’t all used as was originally foreseen; for example, the .GOV and .MIL domains were not used for all types of government and military organizations, but primarily for the United States federal government and military. .EDU ended up being used only for universities, again in the United States. This left only three common top-level domains – .COM, .NET and .ORG – for almost all other groups and companies that wanted to use the organizational hierarchy. Since there were only three such TLDs, they quickly became very “crowded”, especially the .COM domain. A new fourth domain, .INT for international organizations, was added fairly soon to the original seven, but it too was only for a small number of organizations, such as international standards bodies.These TLDs are intended to provide a place for all companies and organizations to be named based on their organization type. There were originally six such domains, but this has been expanded so that there are now fifteen to meet the growing needs. Please refer to the below link for the complete list :

http://www.iana.org/domains/root/db/#

Country Code Top Level Domain (ccTLD)

In theory, the gTLDs would have been sufficient to meet the needs of all the individuals, companies and groups in the world. This is especially true since .ORG by definition is a “catch all” that can include anyone or anything. However, back at the beginning of DNS, its creators recognized that the generic TLDs might not meet the needs of everyone around the world. There are several reasons for this, chief among them:

American Monopoly of the Generic Domains : The United States organizations and companies dominate the generic TLDs. This is not surprising, given that the Internet was first developed in the U.S.A., but it still presents a problem for certain groups. For example, if the United States military controls the .MIL domain where does, say, India’s military fit into the name space?

Language : Most of the generic domains are populated by organizations that primarily do business in English. There are hundreds of languages in the world, however, and it’s easier for the speakers of those tongues if they can more readily locate resources they can understand.

Local Control : Countries around the world rarely agree on much, and they certainly differ on how organizations within their nations should have their Internet presence arranged. There was a desire on the parts of many to allow nations to have the ability to set up subsets of the name space for their own use.

For these and other reasons, the Internet’s name space was set up with a set of country code top-level paralleling the generic ones, sometimes called / ccTLD / or geopolitical TLDs since they are based on geopolitical divisions of the world. In this hierarchy, every country of the world is assigned a particular two-letter code as a top-level domain, with a specific authority put in charge of administering the domain. For example, the ccTLD for Great Britain is “.UK”, the one for Canada “.CA” and the one for Japan is “.JP”. The codes often are more meaningful in the local language than in English, incidentally; Germany’s is “.DE” and Switzerland’s “.CH”. Refer to the following link for the complete list :

http://www.iana.org/domains/root/db/#

Each country has the authority to set up its TLD with whatever internal substructure it chooses; again, this is the power of a hierarchical structure. Some countries enforce a further geographical substructure at the lower levels. For example, the .US domain for the United States was originally set up so that all second-level domains were two-letter state abbreviations (this was later changed). Below  is the reason

Disadvantage of strict ccTLD implementation :

For eg: We need to know about a company which is located in Germany, say BMW (wow!). As per the ccTLD basis the company site should be somewhat www.bmw.de . The question is, what if we never knew the location of company ? We will obviously not sit and try suffixing those 200 ccTLDs out there. The most obvious URL that we Internet users would type into the browser would be www.bmw.com since we know it is a commercial organization. So this is where the popularity of gTLDs  are exhibited. (Ofcourse with today’s search engines like google, we can manage to find that out. But what if it is the domain of a small store in an unknown country and we do not have the time to google it out ?)

Another fine eg would be this : In the U.S , the authority in charge of this domain chose to make it follow a strict geographical hierarchy, so every domain must be of the form “organization.city.state-code.US”. So, to use this part of the name space, a company “xyz”in Boston must be within the “xyz.boston.ma.us” domain. This format has made the name more longer and harder to guess. Further,  if you weren’t aware of the city in which the company is located,  it would have added to the trouble finding it out. Finally, the .US authority eventually abandoned the strict geographical hierarchy due to its non-acceptance.

IANA is responsible for management of the DNS root zone. The role is in assigning the operators of top-level domains, such as .UK and .COM, and maintaining their technical and administrative details.

Root Zone Database : IANA’s Root Zone Database contains the authoritative record of the operators of various top-level domains. The Root Zone Database represents the delegation details of top-level domains, including gTLDs such as “.COM”, and country-code TLDs such as “.UK”. As the manager of the DNS root zone, IANA is responsible for coordinating these delegations in accordance with its policies and procedures.

DOMAIN NAME REGISTRY, DOMAIN NAME REGISTRAR & DOMAIN NAME REGISTRANT

or  simply

REGISTRY, REGISTRAR  &  REGISTRANT

A domain name REGISTRY, is a database of all domain names registered in a top-level domain. A registry operator, also called a Network Information Center (NIC), is the part of the Domain Name System (DNS) of the Internet that keeps the database of domain names, and generates the zone files which convert domain names to IP addresses. Each NIC is an organisation that manages the registration of Domain names within the top-level domains for which it is responsible, controls the policies of domain name allocation, and technically operates its top-level domain. It is potentially distinct from a domain name registrar.

A domain name REGISTRAR is an organization or commercial entity, accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or by a national country code top-level domain (ccTLD) authority, to manage the reservation of Internet domain names in accordance with the guidelines of the designated domain name registries and offer such services to the public. Such a registrar is know as “Accredited Registrar” or “Designated Registrar”.

A domain name REGISTRANT is a person/organization who/which  owns a domain name in the webspace ( i.e. in the world of Internet) so that he /it can create a website and start sharing information on the Internet. Or going by the name, a registrant is the one which approached a registrar and has registered a domain name in his name and is the owner of it. Once became a registrant of a domain name, he is the sole owner of it and no other person on the planet can request for the same domain name in the Internet’s webspace or namespace until the domain name gets expired and is deleted from the registry thereby becoming publically available.

Did you know a few hosts out there, register the domain name in their own names and not yours ? Get the domains registered in your name.

Explanation

Please refer to the links for the list of gTLDs & ccTLDs. In the tables for gTLDs and ccTLDs, Sponsoring Organisation mentioned, is the “Domain Name Registry” for the respective domain. These organisations have been directly authorized by ICAAN to hold the Root Zone Database for the domains they are handling i.e. a  domain registry comes just  below the  ICANN/IANA  in the  DNS  authority hierarchy. One of the famous registry is “Verisign” which handles .COM and .NET domains, NeuStar Inc. for .BIZ etc. This means that they are the ultimate authority (excluding ICANN/IANA) for matters pertaining to the TLDs they handle.

In the young age of the DNS, they (Sponsoring Organisation) handled all the name registrations of the domain under their authority. Later on as the Internet became more crowded, the load on them increased. Further more, these organisations increased the charges for registration (Grreeed is human nature ). So with the aim to increase competition in this field and decrease the rates, ICANN made the domain name registration more public i.e. they started lending out the registration right to other private firms. These firms will now have the power to register a domain name into the world of Internet. For this, they will have to register with ICANN for the TLD domain they are interested in. Once they get registered, they will be an ICANN “Accredited Registrar” or “Designated Registrar” or simply a “Domain Name Registrar” (eg: goDaddy). For becoming an accredited registrar, one need not contact ICANN directly. They will have to find out which is the “Domain Registry” for the TLD they are interested in and just register at the particular registry’s website. This is one of the main differences between a “registry” and a “registrar”. A particular TLD’s registry has the power to authorize a 3rd party as that TLD’s accredited registrar and people who wish to start a domain(or website) can buy a domain name from this registrar. One can become an accredited registrar for more than 1 TLDs. For eg : if a company needs to become the accredited registrar for the TLDs – .com , .biz  and  .coop , they will have to individually register with the : VeriSign Global Registry Services, DotAsia Organisation Ltd. and DotCooperation LLC respectively. Once they get registered  they attain the “Accredited Registrar” status for the TLDs .COM, .BIZ & .COOP. Their company name will automatically be entered into the “Accredited Registrar” list of ICANN. The company can then go onto provide domain names under .COM, .BIZ & .COOP to clients.

So the IANA/ICANN is responsible for  maintaining the DNS ROOT which is the upper-most part of the DNS hierarchy, and involves delegating administrative responsibility of “top-level domains”, which are the last segment of a domain name, such as .com, .uk and .nz. Part of this task includes evaluating requests to change the operators of country code domains, as well as day-to-day maintenance of the details of the existing operators.

NUMBER SYSTEM

IANA is responsible for global coordination of the Internet Protocol addressing systems, as well as the Autonomous System Numbers (ASN) used for routing Internet traffic. Just like maintaining the Name system, IANA has its subsidiaries for looking after the Number system.

The IP address is a Number resource that IANA manages in addition to many others. The task of assigning IPv4 and IPv6 to the end user in Internet is done in a 2 level hierarchy :

Level 1  : RIR – Regional Internet Registry
( there is no such technical term for this hierarchy separation as “level 1″ & “level 2″…just mentioned for clear understanding)

The RIRs manage the allocation of IP addresses on a continent basis. These RIRs have the authority to re-allocate them within their respective geographical areas (of continental scope). There  are accordingly  5  RIRs covering the whole globe. The RIRs are the ones which are directly below the IANA in hierarchy. They are :

AFRINIC (for African Continent) : AfriNIC is a non-government, not-for-profit, membership based organization, based in Mauritius that serves the African Internet Community. AfriNIC is the Regional Registry for Internet Number Resources for Africa.   (http://www.afrinic.net)

APNIC ( for Asia Pacific region) : APNIC is a not-for-profit organization providing Internet addressing services to the Asia Pacific. It includes India , China , Japan, Aus etc..http://www.apnic.net/)

ARIN (North America Region) : American Registry for Internet Numbers (ARIN). It covers USA, Canada etc…(https://www.arin.net)

LACNIC (Latin America and some Caribbean Islands) : It is a Latin American and Caribbean Islands Internet Registry. (http://lacnic.net/)

RIPE NCC (for Europe, Middle East and parts of Central Asia) : Réseaux IP Européens Network Coordination Centre. (http://www.ripe.net/)

Level 2 : NIR – National Internet Registry

( this is an intermediate registry only for APNIC. for other RIRs it will have another name. )

The NIR is an organization directly under the umbrella of a RIR with the task of coordinating IP address allocations and other Internet resource management functions at a national level within a country.

The following NIRs are currently operating in the APNIC region:

* CNNIC, China Internet Network Information Center
* JPNIC, Japan Network Information Center

Level 2 : Local Internet Registry or Internet Service Provider

( this is again level 2 since it is for RIRs other than APNIC )

An Internet Service Provider(ISP) , also sometimes referred to as an Internet Access Provider (IAP), is a company that offers its customers access to the Internet. The ISP connects to its customers using a data transmission technology appropriate for delivering IP datagrams as dial-up, DSL, wireless or dedicated high-speed interconnects. In India we have the following ISPs : BSNL, Reliance, TATA etc..

And finally from the organisations in the Level 2 we the end users get the connection.

Thus in the paragraphs above we saw the authority hierarchy in the management of Internet’s NAMES & NUMBERS.

In addition to this IANA also directly manages  :

1) .INT : designed for the sole use of cross-national organisations, such as treaty organisations, that do not naturally fit into a specific country’s top-level domain. For example, the World Health Organisation uses who.int for its Internet presence, whilst NATO uses nato.int

2) .ARPA : The .arpa domain is used internally by Internet protocols, such as for reverse mapping of IP addresses

3) IDN Practices Repository : Internationalized domain names are domain names represented by native language characters. The native language domain name will be followed by .com or .net. IANA maintains a collection of “IDN tables”, which represent permitted code points (letters) allowed for Internationalised Domain Name registrations in particular registries

4) Protocol Assignments :  IANA is responsible for maintaining many of the codes and numbers contained in a variety of Internet protocols.

Note : Having understood all these one might still wonder the difference between IANA & ICANN. IANA is one of the Internet’s oldest institutions, with its activities dating back to the 1970s. Today it is operated by ICANN, an internationally-organized non-profit organization set up by the Internet community in Sept. 30 1998 to help coordinate IANA’s areas of responsibilities. Thus basically there is no difference between them. So their names are used interchangeably in many contexts.

Tweet This Post

Solution which should have been suggested was UCC certificates and not Wildcard SSL certificates. From GoDaddy’s KnowledgeBase at http://help.godaddy.com/article/3908 here is the definition for UCC or Multi domain certificates.

Unified Communications Certificates (UCC) are SSL Certificates that secure multiple domains and multiple hostnames within a domain. They allow you to secure up to 100 domain names in a single certificate and can consolidate all your secure domains into one certificate.

I believe UCC works based on subjectAltName directive of openSSL, which you can read more about at http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_

Upto 5 domains, it will cost $90 and with GoDaddy’s coupon codes you may be able to get it with 10 to 20% discounts We are no way affiliated to GoDaddy or NoDaddy. But not sure of other providers who gives UCCs at lower rate. If you are aware of one, please feel free to comment!

However we had to make it work for the customer and we did it. Since it was a cPanel server having EasyApache 3, we had to do custom modification for the virtualhosts inorder to make sure that it worked even after the changes are made. How to do that will be in one of the next posts, soon.

Tweet This Post