How to obtain a digital certificate for free

About digital certificates

A digital or SSL certificate consists of two encryption keys, one public and one private, a very common use for digital certificates is to encrypt data exchanges in between a user Internet browser and any e-commerce website but it can also be used to sign documents, encrypt and digitally sign email messages and identify yourself online. Once a digital certificate has been installed in your Internet browser or email client, it is easier to use than encryption software, many users are not even aware they are using it, if the SSL certificate is personalized a password might be asked before using it.

Typical digital certificates will contain a serial number, signature algorithm, issuing authority, valid from and expiry date, public key and a hashed number to guarantee that the key has not been tampered with.

Places to obtain a free digital certificate

CAcert: To be issued an SSL X.509 standard certificate you are asked you to join the CAcert community filling in an online form, in between others you can use CAcert certificates to secure websites, digitally signing or encrypting emails and files.

GetaCert: Not a Certificate Authority (CA), GetaCert appears to be a website using OpenSSL to create a digital certificates online, they can be issued for use with email and websites, all of their certificates are valid for 10 years and wildcards are supported.

StartSSL: Issuing free Class 1 (for individuals) SSL certificates valid for one year, renewable after expiration, security is as good as StartSSL paid for digital certificates but with some limitations like no wildcards allowed and it doesn’t hold identification details.

If you only need a digital certificate to sign and encrypt email you can get Comodo email SSL certificate.

Types of basic digital certificates

• Personal certificate: It works as a digital ID guaranteeing that the person is not someone else, a personal certificate can be used to identify yourself over the Internet with a company or Government agency, digitally sign an email message or a PDF file, a password will normally be asked when carrying out these tasks, using the something you have and something you know security model.

Diagram digital certificate encryption

• Server certificate: It identifies a user when establishing a connection before transmitting any information, email and Usenet servers use a server certificate when authentication takes place via SSL.

• Software certificate: It verifies software before installing it in your computer by checking the code digital signature making sure the program has not been replaced by malware having been signed by a genuine developer, useful when downloading software from the Internet.

Unrecognised digital certificates warnings

All Internet browsers come with digital certificates installed, these are issued by certification authorities like VeriSign or GeoTrust, when the browser comes across a website using a digital certificate which public key is not found in the browser you will get a not recognised certificate warning, this does not mean the site is not safe, it only means one of the key pairs has not been stored in the browser.

It is impossible to have every single company SSL certificate stored in the browser, when you get this kind of warning you should check the digital certificate making sure it is not a man in the middle attack by looking at its properties, when satisfied that everything looks correct, install it, after that you will not get any more security warnings when visiting that site.

Digital certificate security warning

When you install software you could find Windows warning you that the driver has not been digitally signed, Microsoft charges a huge amount for this ‘”privilege” and not all developers can’t afford it, it doesn’t necessarily mean the software is dangerous, it only means it has not been approved by Microsoft.

How to make your own SSL certificate

An alternative to companies issuing free SSL certificates is to create your own Certificate Authority or self-signed digital certificate using OpenSSL, an open source implementation of SSL and TLS, any decent Linux distribution will come with OpenSSL installed, you will need some basic Unix knowledge, go to the command line generate an RSA private key, generate a Certificate Signing Request (CSR) and generate a self-signed certificate, for the necessary commands to do this type man openssl at the Linux command prompt.

You can use OpenSSL and other Unix utilities in Windows using Cygwin, a Unix framework for Windows, it is beyond the scope of this article to explain how Cygwin works.

Tq http://www.hacker10.com/

How to Generate An SSL Certificate For Your Website

If you run a website which you need to serve via SSL, then this article is for you. The procedure for making your website SSL ready is quite simple. It involves -

1. Generating a private key.
2. Generating a Certificate Signing Request (CSR).
3. Getting the CSR signed by a certificate authority - Verisign, Go Daddy, Thawt etc. (Be ready to shell out some money here).
4. Uploading the private key, the CSR, and the certificate to your website.
5. Configuring the SSL version of your site. And finally ...
6. Enabling the SSL for your website.

ScoutApp has a nice article that explains the above steps in detail. Check it out.

Tq http://linuxhelp.blogspot.com

Apache Web Server Security

The increase in cyber attacks on high profile online business websites implies that web security still needs to be addressed. Exploits of web server vulnerabilities typically have a more disastrous and visible impact. While with web application vulnerabilities a malicious user could gain access to a database and other form of stored data, with web server software vulnerabilities, a malicious user could even gain access to the operating system, potentially compromising the whole network.

A brief introduction to Apache web server

The Apache Foundation released Apache Version 2 in 2002, following on the success of Apache Web Server version 1. Version 2 was almost a total rewrite, which mostly focused on further modularization and development of the Apache core. Apache Version 2 has several improvements, which include Unix threading, IP version 6 support and most importantly of all, better support for non-Unix platforms, such as Microsoft Windows. These improvements helped Apache web server to become the first web server used to host over 100 million websites and web applications on the internet, thus being the most widely used web server.

Securing Apache web server

The following suggestions will go a long way in improving the security of an Apache web server installation. Despite applying the ‘less is better’ rule to harden a web server by disabling a number of modules, it will not be enough. It is still recommended to apply all security patches in case a disabled module is enabled in the future.

Limit server functionality

One must first be aware of which function or functions the web server will be used for. Will it serve HTML pages only, or also execute a number of scripts? Enabling support for PHP, ASP.NET and other similar web technologies will only increase the attack surface which a malicious user could penetrate. This might happen because of vulnerabilities in a specific web server module. Therefore one should only support web technologies which are going to be used.

Limit access to operating system and its files

The operating system on which the Apache web server will be running must also be hardened. For more information on how to secure a web server operating system, click here. It is important that the Apache web server process runs under a unique user ID, which must not be used by any other system processes. Apache processes must also have limited access to the operating system files (chrooting). Chrooting is the process of creating a new root directory structure where all Apache daemon files are moved to. As a result of the chrooting process, the Apache web server daemon will only have access to the new directory structure. No shell programs e.g. /bin/sh, /bin/csh/ should be present in the Apache’s chrooted environment. This way the web server benefits immunity from a large number of existing exploits.

Disable unnecessary web server modules

Apache is shipped with a number of pre-enabled modules to be more user friendly. This is a bit of a break from its Unix past of only providing the essential. In this case, the ‘less is better’ rule is to be applied with more diligence and the choice of which module to enable is probably the most important step. An administrator would avoid potential break-ins simply by disabling unnecessary modules when new vulnerabilities are found in them. Check about every pre-enabled module to confirm if it is needed, and if not, disable it.

Tighten the Apache configuration

The default Apache configuration contains a large number of directives that are not used in a typical scenario. One can safely switch off or disable the directives listed below if not being used:

• directory indexes
• unnecessary default ‘Alias’ and 'ScriptAlias’
• Handlers (only leave handlers which you will be using. Remove all others)
• Directory Options such as ‘FollowSymLinks’ (if no symbolic links are used in the web directories)

Friendly web server error messages should also be configured, to make sure that the least amount of information is disclosed about the Apache web server installation and configuration. If possible, the web server banner should also be obfuscated (security by obscurity).

Disable Server Sides Includes

SSIs bring along a number of potential security risks with them. Most important of all, SSI-enabled web documents will severely increase the load on the server. In high traffic websites or in a shared web hosting environment, such load can become very significant. Furthermore, server sides includes pose the same number of risks associated with CGI (Common Gateway Interface) scripts in general. SSI-enabled files, can execute any CGI script or program under the permissions of the user which the Apache web server runs on, thus posing a huge security risk. A number of web technologies that avoid using SSI and transfer the processing required to the client / browser side are available today. A web master should take advantage of such web technologies.

Monitor log files

Proper web application access and web server operation logging should be enabled. Such logs should not be placed in the web server root directory. As with any other internet service, it is important to check all of Apache’s log files regularly. Analysing past events from web server log files, will give the administrator a good idea of what attack trends are being followed. This will also help the administrator identify where the web server needs tightening up.

Install all Apache web server updates

From time to time, Apache Foundation release a number patches. It is always a good practice to keep the Apache web server installation up to date, despite of whether the patch is a security patch, or a software update. Subscribe to a mailing list such as ‘Apache Server Announcements’ to receive notifications of when updates and patches are available. Such mailing lists are hosted by the Apache Foundation.

Stay informed and frequently check the web server configuration

A number of books, online security guidelines articles and white papers are available to help an administrators secure an Apache web server installation and implement the above security suggestions, which are however universal. It is suggested to read such articles and follow the guidelines. After applying such changes, it is also important to test the web server’s and web application’s functionality, to confirm that such changes did not hinder any of the web application’s functionality. The use of third party security tools, such as Acunetix WVS can help confirm that the applied procedures did improve your web server security. Acunetix WVS will also launch a number of security checks against an Apache web server, and will also check for weak configurations. Take a product tour of Acunetix Web Vulnerability Scanner or download it today!

IIS Web Server Security

With the sharp increase of hacking attacks over the last couple of years, and the introduction of a number of regulatory compliance guidelines to follow, web application security has become a key concern for many online businesses, and also a common expense in a company’s budget. Although many businesses are focusing on securing their web applications, unfortunately they are not looking at the whole picture. A vital part of securing a business’s whole web infrastructure also includes having a secure web server configuration. Securing a web server’s configuration is as important as securing the web application itself.

A brief introduction to Microsoft IIS

Microsoft Internet Information Services, better known as IIS, is Microsoft’s set of internet based services for servers, which runs on Microsoft Windows operating systems. The internet services provided with IIS are a SMTP (simple mail transport protocol) Server, FTP (file transfer protocol) Server, NNTP (network news transfer protocol) server and WWW (World Wide Web) server. Until version 5.1 (~ year 2000), IIS was hit with a number of vulnerabilities, which also lead to a number of infamous worms on the internet, such as the Code Red Worm. Most of such incidents happened because both the design of the application itself and the permissions it used to run were flawed. An out of the box installation of IIS version 5.1 published on the internet in 2000, could get hacked in a matter of minutes. From version 6 onwards, when internet hacking was causing a huge financial problem to major online businesses, Microsoft re-designed IIS. The way IIS 6 and more recent versions work and use resources, are more secure, and help in reducing the attack surface. Microsoft also removed the SMTP server and the NNTP server in more recent versions of IIS. Still, an out of the box IIS installation, with a default configuration may still lead to a number of problems.

Securing your Microsoft IIS web server

1. To start off with, all web related documents, such as web application files and other files which are typically shared over the internet, should be stored in a different drive from the operating system drive. Because of vulnerability, a malicious user can gain access to the web root directory, and then escalate his permissions and gain access to the whole drive where the web root is. If the malicious user gains access to the whole drive, at least he cannot tamper your operating system installation, thus making it easier to trace his activity.

2. When creating a new web root directory, where all the files to be shared on the web will be stored, grant the appropriate (least possible) NTFS permissions to the anonymous user being used from the IIS web server to access the web content. Ideally, deny write access to any file or directory in the web root directory to the anonymous user. If need be, create a new user to be used as an anonymous user and grant the appropriate permissions, and disable the built-in IIS anonymous user. Always avoid giving write NTFS permissions to the anonymous user.

3. If a database server, such as Microsoft SQL Server is to be used as a backend database, install it on a separate server. If the budget permits, other network services should be installed on separate servers. If one of such network services is compromised, it makes it more difficult for a malicious user to gain access over the other servers, thus compromising the whole web farm infrastructure. Also, if possible, avoid mapping virtual directories between two different servers, or over a network.

4. If IIS FTP service is needed, do not install the FTP service shipped with latest windows editions. Apart from not being a very practical FTP server, its configuration has to be accessed from a IIS 6 management console. Microsoft released a new FTP server which integrates better with IIS 7 and its configuration, and is more practical. It can be downloaded from the following URL (IIS Official website); http://learn.iis.net/page.aspx/310/what-is-new-for-microsoft-and-ftp-75/. One should also follow good FTP server configuration practices, such as to always isolate the ftp user in his home directory, use secure FTP (over SSL), and also allow the least possible privileges to the users. Even though FTP user permissions can be controlled from the IIS 7 MMC, make sure that such permissions are also enforced via NTFS permissions. If port scanning is enabled in Acunetix WVS, it will also check your FTP server configuration, and will launch a number of security checks against the FTP server.

5. Monitor servers, web applications and network services activity frequently. By analysing the log files, you can determine if a web server or network service is being attacked. Studying such activity, you can also learn what type of attacks your server is undergoing, thus helping you understand the attacker and will also help you adapt to such attacks and increase the level of security of the whole web farm infrastructure.

6. Like every other software vendor, Microsoft periodically releases a number of software updates and security patches. These patches should be applied at the earliest possible to reduce the risk of someone finding the security hole before it is patched. Once vulnerabilities are made public, within a couple of hours, malicious users would already have automated scripts and scanners that crawl the internet and identify vulnerable server. Once a new security patch or software update is applied, you should also thoroughly test the web applications’ functionalities, to confirm they were not affected by such security patch or software update.

7. Microsoft provides a number of tools to help you secure your web server. It is imperative to invest time in learning how to use such tools, since in the long run they can save you from a more time consuming activity, such as restoring a server after it was hacked, or tracing a malicious user’s activity. Such tools are; IIS Security “What if” tool, which helps you troubleshoot security issues with IIS, IIS Security Planning Tool which helps you deploy IIS with security that is appropriate for the server’s role, and IIS Lockdown tool, which provides built-in secure IIS configuration templates. There are many other tools provided from Microsoft for free, which can be downloaded from their website. Also, Microsoft frequently publishes documents and security guidelines on how to secure your web server, which one should follow. After using such tools, or applying changes which you’ve learnt about from Microsoft’s documentation, test the web application’s functionality, to confirm that such changes did not affect or block any of the web application’s functionality. Ideally you should also use other third party security tools, such as Acunetix WVS to confirm that such tools are properly securing your web server.