How To Create a SSL Certificate on nginx

ABout Self-Signed Certificates


A SSL certificate is a way to encrypt a site’s information and create a more secure connection. Additionally, the certificate can show the virtual private erver’s identification information to site visitors. Certificate Authorities can issue SSL certificates that verify the server’s details while a self-signed certificate has no 3rd party corroboration.

Set Up

You need to have nginx already installed and running on your VPS.
If this is not the case, you can download it with this command:

sudo apt-get install nginx

Step One—Create a Directory for the Certificate


The SSL certificate has 2 parts main parts: the certificate itself and the public key. To make all of the relevant files easy to access, we should create a directory to store them in:

 sudo mkdir /etc/nginx/ssl

We will perform the next few steps within the directory:

 cd /etc/nginx/ssl

Step Two—Create the Server Key and Certificate Signing Request


Start by creating the private server key. During this process, you will be asked to enter a specific passphrase. Be sure to note this phrase carefully, if you forget it or lose it, you will not be able to access the certificate.

sudo openssl genrsa -des3 -out server.key 1024

Follow up by creating a certificate signing request:

sudo openssl req -new -key server.key -out server.csr

This command will prompt terminal to display a lists of fields that need to be filled in.

The most important line is “Common Name”. Enter your official domain name here or, if you don’t have one yet, your site’s IP address. Leave the challenge password and optional company name blank.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Texas
Locality Name (eg, city) []:Dallas
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Awesome Inc
Organizational Unit Name (eg, section) []:Dept of Merriment
Common Name (e.g. server FQDN or YOUR name) []:example.com                  
Email Address []:webmaster@maanas.co

Step Three—Remove the Passphrase


We are almost finished creating the certificate. However, it would serve us to remove the passphrase. Although having the passphrase in place does provide heightened security, the issue starts when one tries to reload nginx. In the event that nginx crashes or needs to reboot, you will always have to re-enter your passphrase to get your entire web server back online.

Use this command to remove the password:

sudo cp server.key server.key.org
sudo openssl rsa -in server.key.org -out server.key

Step Four— Sign your SSL Certificate


Your certificate is all but done, and you just have to sign it.

Keep in mind that you can specify how long the certificate should remain valid by changing the 365 to the number of days you prefer. As it stands this certificate will expire after one year.

 sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

You are now done making your certificate.

Step Five—Set Up the Certificate


Now we have all of the required components of the finished certificate.The next thing to do is to set up the virtual hosts to display the new certificate.

Let’s create new file with the same default text and layout as the standard virtual host file. You can replace “example” in the command with whatever name you prefer:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example

Then go ahead and open up that new file:

 sudo nano /etc/nginx/sites-available/example

Scroll down to the bottom of the file and find the section that begins with this:

# HTTPS server

server {
        listen 443;
        server_name example.com;

        root /usr/share/nginx/www;
        index index.html index.htm;

        ssl on;
        ssl_certificate /etc/nginx/ssl/server.crt;
        ssl_certificate_key /etc/nginx/ssl/server.key; 
}

Uncomment within the section under the line HTTPS Server. Match your config to the information above, replacing the example.com in the “server_name” line with your domain name or IP address. Subsequently, add in the correct directory for your site (the above configuration includes the default nginx page).

Additionally, make sure that both of these lines are commented out in the line toward the beginning of the file that says:

# Make site accessible from http://localhost/
# server_name localhost;

Step Six—Activate the Virtual Host


The last step is to activate the host by creating a symbolic link between the sites-available directory and the sites-enabled directory.

 sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example

Then restart nginx:

 sudo service nginx restart

Visit https://youraddress You will see your self-signed certificate on that page!

How to Create a SSL Certificate on Apache for CentOS 6

About Self-Signed Certificates


A SSL certificate is a way to encrypt a site’s information and create a more secure connection. Additionally, the certificate can show the virtual private server’s identification information to site visitors. Certificate Authorities can issue SSL certificates that verify the virtual server’s details while a self-signed certificate has no 3rd party corroboration.

Step One—Install Mod SSL


In order to set up the self signed certificate, we first have to be sure that Apache and Mod SSL are installed on our VPS. You can install both with one command:

yum install mod_ssl

 

Step Two—Create a New Directory


Next, we need to create a new directory where we will store the server key and certificate

mkdir /etc/httpd/ssl

 

Step Three—Create a Self Signed Certificate


When we request a new certificate, we can specify how long the certificate should remain valid by changing the 365 to the number of days we prefer. As it stands this certificate will expire after one year.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/apache.key -out /etc/httpd/ssl/apache.crt

With this command, we will be both creating the self-signed SSL certificate and the server key that protects it, and placing both of them into the new directory.

This command will prompt terminal to display a lists of fields that need to be filled in.

The most important line is “Common Name”. Enter your official domain name here or, if you don’t have one yet, your site’s IP address.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:NYC
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Awesome Inc
Organizational Unit Name (eg, section) []:Dept of Merriment
Common Name (e.g. server FQDN or YOUR name) []:example.com                  
Email Address []:webmaster@awesomeinc.com

 

Step Four—Set Up the Certificate


Now we have all of the required components of the finished certificate.The next thing to do is to set up the virtual hosts to display the new certificate.

Open up the SSL config file:

 vi /etc/httpd/conf.d/ssl.conf

Find the section that begins with <VirtualHost _default_:443> and make some quick changes.

Uncomment the DocumentRoot and ServerName line and replace example.com with your DNS approved domain name or server IP address (it should be the same as the common name on the certificate):

 ServerName example.com:443

Find the following three lines, and make sure that they match the extensions below:

SSLEngine on
SSLCertificateFile /etc/httpd/ssl/apache.crt
SSLCertificateKeyFile /etc/httpd/ssl/apache.key

Your virtual host is now all set up! Save and Exit out of the file.

Step Five—Restart Apache


You are done. Restarting the Apache server will reload it with all of your changes in place.

 /etc/init.d/httpd restart

In your browser, type https://youraddress to view the new certificate.

DNS: Setup bind9 DNS Server in chroot environment

– Install Bind
# yum -y install bind bind-chroot bind-libs bind-utils caching-nameserver

-Confgure Permision
# chmod 755 /var/named/
# chmod 775 /var/named/chroot/
# chmod 775 /var/named/chroot/var/
# chmod 775 /var/named/chroot/var/named/
# chmod 775 /var/named/chroot/var/run/
# chmod 777 /var/named/chroot/var/run/named/
# cd /var/named/chroot/var/named/
# ln -s ../../ chroot
# cp /usr/share/doc/bind-9.3.6/sample/var/named/named.local /var/named/chroot/var/named/named.local
# cp /usr/share/doc/bind-9.3.6/sample/var/named/named.root /var/named/chroot/var/named/named.root
# touch /var/named/chroot/etc/named.conf

– Setting RNDC
# cd /var/named/chroot/etc
# rndc-confgen > rndc.conf
# chown root:named rndc.conf

– Edit File rndc.key:
# nano /var/named/chroot/etc/rndc.key

# Start of rndc.conf
key "rndckey" {
algorithm hmac-md5;
secret "QXkk0JXZDrgi0dJ0DrETKQ==";
};

#options {
# default-key “rndckey”;
# default-server 127.0.0.1;
# default-port 953;
#};
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key “rndckey” {
# algorithm hmac-md5;
# secret “xwINl5E9kGDva0PcJWCZjQ==”;
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { “rndckey”; };
# };
# End of named.conf

– Configure /var/named/chroot/etc/named.conf

# nano /var/named/chroot/etc/named.conf


// Red Hat BIND Configuration Tool
// Default initial "Caching Only" name server configuration
// we include the rndckey (copy-paste from rndc.key created earlier)
// include "/var/named/chroot/etc/rndc.key";
key "rndckey" {
algorithm hmac-md5;
secret "QXkk0JXZDrgi0dJ0DrETKQ==";
};

// assume our server has the IP 192.168.0.11 serving the 192.168.0.0/24 subnet
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { “rndckey”; };
inet 192.168.0.250 allow { 192.168.0.0/24; } keys { “rndckey”; };
};

options {
directory “/var/named”;
pid-file “/var/run/named/named.pid”;

recursion yes;

allow-recursion {
127.0.0.1;
192.168.0.0/24;
};

// these are the opendns servers (optional)
forwarders {
202.134.0.155;
203.130.193.74;
8.8.8.8;
8.8.4.4;
};

listen-on {
127.0.0.1;
192.168.0.250;
};

/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;

// so people can’t try to guess what version you’re running
version “REFUSED”;

allow-query {
127.0.0.1;
192.168.0.0/24;
};
};

server 192.168.0.250 {
keys { rndckey; };
};

zone “.” IN {
type hint;
file “named.ca”;
};

//forward zone
zone “example.net” IN {
type master;
file “data/example.net.zone”;
allow-update { none; };
// we assume we have a slave dns server with the IP 192.168.0.251
allow-transfer { 192.168.0.251; };
};

//reserve zone
zone “0.168.192.in-addr.arpa” IN {
type master;
file “data/192.168.0.zone”;
allow-update { none; };
// we assume we have a slave dns server with the IP 192.168.0.251
allow-transfer { 192.168.0.251; };
};

-Setting Forward Lookup Zone
# cd /var/named/chroot/var/named/data/
# touch example.net.zone
# nano example.net.zone

-Edit File example.net.zone:

$ttl 38400
example.net. IN SOA ns.example.net. admin.example.net. (
2012011501 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
;
example.net. IN NS ns.example.net.
ns.example.net. IN A 192.168.0.250

– Setting Reverse Lookup Zone
# cd /var/named/chroot/var/named/data/
# touch 192.168.0.zone
# nano 192.168.0.zone

-Edit File 192.168.0.zone :

$TTL 86400
0.168.192.in-addr.arpa. IN SOA ns.example.net. admin.example.net. (
2012011502
10800
900
604800
3600 )

0.168.192.in-addr.arpa. IN NS ns.example.net.-Restart Bind Service & Setting run level

# service named restart
# chkconfig named on

-Make sure it’s running :
# rndc status

If it is not running link /etc/rndc.conf with /var/named/chroot/etc/rndc.conf and restart named

-Edit /etc/resolv.conf & Restart service
# nano /etc/resolv.conf

search example.net
nameserver 127.0.0.1
nameserver 192.168.0.250
nameserver 192.168.0.251

-Testing DNS Query:
# nslookup google.com

Debugging .htaccess

Debugging .htaccess is at time shooting in dark. I had gone through one such day where every thing makes sense but it does not work. I had outlined the step i used to find out the bug.

Add a Garbage inside the .htaccess to see whether you get Server Error. If you get a server error it is working

<IfModule mod_rewrite.c>

#Options +FollowSymlinks

This is Garbage and should result in failure

RewriteEngine On
RewriteBase /
RewriteRule ^(.*$ /deubg.php?$1 [QSA]
</IfModule>

If you get a server error then there is some problem in the your .htaccess config. You can try the online .htaccess tool to debug the same

http://htaccess.madewithlove.be/

If you do not get a .htaccess error then .htaccess is not read by the Apache

  1. Open the Apache configuration file located at /etc/httpd/conf/httpd.conf
  2. Change AllowOveride None to AllowOveride All inside the DocumentRoot Directory Directive, normally<Directory “/var/www/html”>
This will allow the directives to be modified.

Moving to Hetzner.de from prgmr.com

prgmr.com is very good VPS service which offer good value for money if you are comfortable with command line. In my two years experience with them i had occasional outage. Over all very satisfactory.

Now i m planning to move over to hetzner.de and buy their EX service root server. I hope to utilize my VPS experience to install a Xen Server 5.6 Sp2 on it. Then may be install couple of bunch of VMs to do testing and Dev machines for the consultants,

Automated Install Xenserver Hetzner for EX4S Guest Networking Enabled

Skip to end of metadata

  • Hetzner’s gateway setup requires special network settings (all XenServer releases)
  • the XenServer 5.6 unattended installation has a bug so the installed system will not boot
  • XenServer 5.6 FP1 has a problem with the RealTek 8169 NIC which are used in Hetzner’s servers

This article explains how to circumvent these problems. Some workarounds are needed even when installing from a physical CD (by using Hetzner’s LARA console).

This How-To also works for XenServer 5.61 SP2

Copy contents of the installation CD to a directory on a webserver

Copy the contents of the Citrix XenServer installation CD to a directory on a web server. This directory must be accessible by ip address (in this example it ishttp://192.168.1.141/download/xenserver), so you might need to set up a default virtual host.

# mount -o loop XenServer-5.6.1-fp1-install-cd.iso /mnt
# cp -a /mnt xenserver

Create answerfile

In the xenserver directory, create a new file xenserver.xml containing the following XML code. Make sure to enter your own hostname, root password, ip address, subnet mask, gateway and name server ip addresses. The source URL is of course the URL to the installation directory you have just created. It must contain the ip address, not the domain name.

<installation mode="fresh" srtype="lvm">
 <bootloader>grub</bootloader>
 <primary-disk gueststorage="yes">sda</primary-disk>
 <keymap>de</keymap>
 <hostname>server00</hostname>
 <root-password>topsecret</root-password>
 <source type ="url">http://192.168.1.141/download/xenserver</source>
 <!-- No Post install scripts configured -->
 <admin-interface name="eth0" proto="static">
 <ip>192.168.1.76</ip>
 <subnet-mask>255.255.255.192</subnet-mask>
 <gateway>192.168.1.65</gateway>
 </admin-interface>
 <nameserver>213.133.98.98</nameserver>
 <nameserver>213.133.99.99</nameserver>
 <nameserver>213.133.100.100</nameserver>
 <timezone>Europe/Berlin</timezone>
 <time-config-method>ntp</time-config-method>
 <ntp-servers>ntp</ntp-servers>
 <ntpservers>192.53.103.108</ntpservers>
 <ntpservers>129.69.1.153</ntpservers>
 <ntpservers>134.34.3.18</ntpservers>
</installation>

Configure new server for unattended installation

The new XenServer host must be initialized with an arbitrary Linux system. Its only purpose is to boot a special XenServer kernel, which in turn will start the actual installation process by downloading the answerfile and the installation packages from the web server.

When installing the Linux system, do not use a software raid. There seems to be a bug in the XenServer 5.6 installer: if the Linux system used to boot the XenServer installer had software raid turned on, the installed XenServer system was corrupt. Files were missing or had binary data in them.

To install the initial Linux system, do the following for a Hetzner root server:

  1. boot the server in the rescue console 

  2. wipe all disks so that they do not have partitions of type 0xfd (Linux raid autodetect):
    # dd if=/dev/zero of=/dev/sda count=256
    # dd if=/dev/zero of=/dev/sdb count=256

    Note that this will destroy all data on your disks. 

  3. install Linux using the installimage command. I was using CentOS 5.5 32bit with good success. Remember to turn off the software raid option, this is done by editing the configuration to SW RAID = 0

  4. After installing Linux, mount the boot partition:
    # mount /dev/sda3 /mnt
    # mount /dev/sda2 /mnt/boot
  5. Replace the file /mnt/boot/grub/menu.lst with the following content:
    timeout 5
    default 0
    
    title Install Xenserver
    root (hd0,1)
    kernel /boot/xen.gz dom0_mem=752M acpi=off nosmp noapic noirqbalance
    module /boot/vmlinuz answerfile=http://192.168.1.141/download/xenserver/xenserver.xml install
    module /boot/install.img

    Note that the file references the answerfile created earlier. The URL must contain the ip address, a domain name will not work. 

  6. if there is a file grub.conf, copy menu.lst to it 

  7. some files must be copied from the XenServer installation directory into the /boot directory. On the server containing the XenServer installation files (the web server), do the following:
    scp xenserver/install.img xenserver/boot/vmlinuz xenserver/boot/xen.gz newserver.mydomain:/mnt/boot
    root@newserver.mydomain's password: ********
    install.img     100%   26MB  12.9MB/s   00:02
    vmlinuz         100% 2058KB   2.0MB/s   00:00
    xen.gz          100%  585KB 585.2KB/s   00:00
  8. to see whether the XenServer installer actually retrieves the files from the web server, run the tail command:
    # tail -f access_log.2011-04-16-00_00_00  | grep xenserver
    192.168.1.76 - - [16/Apr/2011:11:36:11 +0200] "GET /download/xenserver/xenserver.xml HTTP/1.1" 200 871 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/XS-REPOSITORY-LIST HTTP/1.1" 200 21 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/XS-REPOSITORY HTTP/1.1" 404 230 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/XS-PACKAGES HTTP/1.1" 404 228 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages/XS-REPOSITORY HTTP/1.1" 404 239 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages/XS-PACKAGES HTTP/1.1" 404 237 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages.main/XS-REPOSITORY HTTP/1.1" 200 145 "-" "Python-urllib/2.4"
    192.168.1.76 - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages.main/XS-PACKAGES HTTP/1.1" 200 3720 "-" "Python-urllib/2.4"
    ...
  9. if you want to install XenServer 5.5, you can now restart the server. You should see the XenServer installer accessing the installation files a couple of minutes later. After the automatic reboot you should be able to connect to the new server via XenCenter 

  10. if you are installing XenServer 5.6, the configuration must be modified before the reboot. Otherwise XenServer will hang during reboot and there is no chance to log in and fix the settings. therefore the Hetzner rescue system must be set up before the XenServer installation finishes. The easiest way to do this is: log into the Hetzner server administration, restart the server, and right after you see the installer accessing the packages from the web server, turn on the rescue system for this server. This way, when the freshly installed XenServer reboots after the installation has finished, it will boot into the rescue mode. 

  11. in the rescue console, mount the disks again. In the file /etc/rc.sysinit, find the following line and comment it out:
    # [ -x /sbin/nash ] && echo "raidautorun /dev/md0" | nash --quiet
  12. After that, edit /etc/modprobe.conf and add the line
    options r8169 use_dac=1
  13. Finally, reboot. The new XenServer 5.6 FP1 system should now be accessible from XenCenter

 

7. Makse sure your /etc/sysctl.conf has this :

# Kernel sysctl configuration file for Red Hat Linux

#

# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and

# sysctl.conf(5) for more details.

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

# Controls proxy arp

net.ipv4.conf.default.proxy_arp = 1

# Turn off redirects

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.lo.send_redirects = 0

net.ipv4.conf.xenbr0.send_redirects = 0

and validated with ’systcl -p’

# sysctl -p

net.ipv4.ip_forward = 1

net.ipv4.conf.default.proxy_arp = 1

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.lo.send_redirects = 0

net.ipv4.conf.xenbr0.send_redirects = 0

net.ipv4.conf.default.rp_filter = 1

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.conf.default.accept_source_route = 0

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

kernel.sysrq = 1

kernel.core_uses_pid = 1

net.ipv4.tcp_syncookies = 1

kernel.msgmnb = 65536

kernel.msgmax = 65536

kernel.shmmax = 4294967295

kernel.shmall = 268435456

vm.dirty_ratio = 5

kernel.printk = 4 4 1 4

8. Disable SeLinux with

# system-config-securitylevel-tui

9. add your additional subnetwork to your xenserver

# ip addr add 78.47.193.23/29 dev xenbr0

10. shutdown the iptables

# service iptables stop

11. Create Dummy interface as we would use this as gateway for all Guest machine (Linux or Windows)

let say you have this Ip subnet from Hetzner 78.47.125.24 until 78.47.125.31.

Network: 78.47.125.24/29

Broadcast: 78.47.125.31

HostMin: 78.47.125.25 (this one we would use as gatway for our guesthost)

HostMax: 78.47.125.30

# nano /etc/sysconfig/network-scripts/ifcfg-xenbr0:1

XEMANAGED=yes

DEVICE=xenbr0:1

ONBOOT=yes

BOOTPROTO=none

NETMASK=255.255.255.248

IPADDR=78.47.193.23

12. bring our xenguest gateway ip up

#ifup xenbr0:1

13. now you can use this range 78.47.125.26 until 78.47.125.30

NETMASK = 255.255.255.248

GATEWAY = 78.47.125.25

NAMESERVER = 213.133.99.99 213.133.100.100